Un certificat SSL ou TLS authentifie un serveur et chiffre les données échangées avec celui-ci. Les données sont ainsi échangées en confiance, entre deux acteurs dont l’identité est connue. Les données échangées ne peuvent être espionnées ni altérées par un tiers : confidentialité et intégrité.
Téléchargez cette fiche « 5 minutes pour comprendre : les certificats SSL / TLS » depuis notre page ressources.
![[INFOGRAPHIE] Les cyberattaques ont explosé en 2020 - Nameshield](https://blog.nameshield.com/fr/wp-content/uploads/sites/3/2021/02/INFOGRAPHIE-2020-explosion-des-cyberattaques-apercu-RS.jpg)
Dans la fiche 5 minutes pour comprendre évoquée dans l’article publié sur ce blog, vous avez pu prendre connaissance des différents modes opératoires utilisés pour les cyberattaques.
Dans l’infographie téléchargeable ici, vous remarquerez à quel point ces cyberattaques ont explosé en 2020, comment les cibles des rançongiciels ont évolué. Une cybercriminalité qui s’est professionnalisée, qui a augmenté de façon exponentielle et qui vise maintenant des sources potentiellement plus lucratives.
Vous découvrirez également quelles sont les autres menaces à ne pas négliger.
Chaque jour, de nouvelles cyberattaques viennent mettre à mal les systèmes de défense des entreprises, et fragilisent encore plus les réseaux, les cyberattaques se succèdent de manière exponentielle.
Découvrez dans cette fiche 5 minutes pour comprendre quelles sont les modes opératoires des cyberattaques les plus courantes et les solutions à mettre en place pour les contrer.
Une part importante des failles de sécurité de l’information dans les entreprises est due à des facteurs humains et cette donnée doit faire l’objet de la plus grande attention de toute entreprise ou institution dont le patrimoine numérique est précieux.
Parce que Nameshield est certifié ISO 27001, l’entreprise se doit d’évaluer régulièrement le niveau de connaissance de ses employés en termes de sécurité de l’information.
L’équipe Sécurité SI a donc concocté et soumis un QCM à l’ensemble des salariés du groupe ; une nette majorité s’est prêtée à l’exercice, agrémenté d’un « jeu des 7 erreurs » pour l’aspect ludique.
Le test a permis de mesurer les acquis et de partager des techniques pour que les bonnes pratiques obtiennent l’adhésion et ne soient pas vécues comme des contraintes pesantes.
Voici quelques unes des questions abordées : Quelles sont les spécificités d’un mot de passe robuste ? Comment le rendre mémorisable ? Quels sont les atouts d’un coffre-fort numérique ? Comment reconnaître un site de vente en ligne officiel ? Où sauvegarder mes fichiers sensibles ? Comment déceler un e-mail de phishing ? Etc.
Nous partageons avec vous le jeu des 7 erreurs. A vous de vous prêter à ce jeu en donnant vos réponses dans les commentaires de notre post LinkedIn ! Celle ou celui qui aura trouvé toutes les mauvaises pratiques en termes de sécurité SI le plus rapidement possible, recevra une récompense !
Le navigateur Chrome représente en octobre 2018, selon les sources et toutes plateformes confondues, entre 62% et 68% de parts de marché mondial. Une croissance d’une régularité implacable depuis le lancement du navigateur qui en fait aujourd’hui un acteur incontournable du web. Alors, quand le 8 septembre 2016, les équipes de développement de Chrome annoncèrent leur intention de déclarer le HTTP comme « not secure », le web dans son ensemble se mit à écouter.
L’objectif de Google était d’avertir simplement, et donc visuellement, l’internaute qu’une page en HTTP n’était pas sûre, d’autant plus pour les pages avec saisies de données à caractère personnel (login, mot de passe, informations personnelles, numéro de carte de crédit) :
” We, the Chrome Security Team, propose that user agents (UAs) gradually change their UX to display non-secure origins as affirmatively non-secure. The goal of this proposal is to more clearly display to users that HTTP provides no data security. ”
Un peu plus de deux ans et 17 versions du navigateur plus tard, le temps d’une transition graduée pour un peu plus de douceur, et Google est arrivé à ses fins avec une adoption massive du protocole HTTPS ; la quasi-totalité des autres navigateurs, Firefox en-tête, ayant suivi la même évolution.
Retour sur l’évolution des indicateurs de sécurité dans Chrome depuis 2 ans :
Septembre 2016 – Chrome 53 : le HTTP est la norme, et en dehors de certaines erreurs de sécurité liées à un défaut de la page (notamment lié aux certificats SSL), aucun indicateur particulier concernant le manque de sécurité
Pour beaucoup c’est un sérieux pas en arrière, il faudra suivre de près cette évolution et penser à mettre en place des certificats SSL Extended Validation EV, qui pour l’instant ne sont pas remis en cause par Google.
Désormais, l’affichage des pages HTTP contenant des informations sensibles pour l’internaute, telles que la saisie de mot de passe ou de numéro de carte de crédit, est barré d’un indicateur non sécurisé et pour la première fois de couleur rouge. Les autres pages HTTP sont indiquées non sécurisées en gris. Les pages HTTPS classiques avec un cadenas noir et celles avec un certificat EV affichent en plus le nom de la société… vous suivez ?
Date non définie – Chrome YY : toujours dans une optique d’augmentation de la sécurité et de protection des identités, Google a dans ses cartons une réflexion en cours sur la fin du système d’url tel que nous le connaissons aujourd’hui… Pour le remplacer par un système nouveau et plus simple, affaire à suivre…D’ici là, et si cette réflexion n’a pas encore été menée au sein de votre entreprise, il est grand temps de passer l’ensemble de vos sites web et applications en HTTPS. La réflexion doit également comprendre le fait d’insérer le nom de votre entreprise dans la barre d’adresse des navigateurs, au moins sur les sites vitrine et à fort trafic.
Le DNSSEC est un vieux serpent de mer qui se concrétise et devient indispensable dans les bonnes pratiques de sécurité prônées par l’ANSSI et par le web d’une manière générale. Et pourtant c’est un terme un peu barbare qui fait souvent peur et dont on ne sait pas trop bien comment ça marche et à quoi ça sert. Cet article a pour humble vocation d’éclaircir tout ça.
Le Domain Name System Security Extensions est un protocole de communication standardisé permettant de résoudre des problèmes de sécurité liés au DNS. Il convient donc de commencer par un petit rappel de ce qu’est le DNS.
Pour faire au plus simple, le Domain Name System (ou Système de Noms de Domaine) est un peu l’annuaire de l’Internet. C’est un service permettant de traduire un nom de domaine en adresses IP. Il s’appuie sur une base de données distribuée sur des millions de machines. L’être humain arrive beaucoup plus facilement à identifier, mémoriser et différencier des noms que des suites de chiffres, le DNS a ainsi été défini et implémenté dans les années 80 pour devenir une brique fondamentale (et souvent oubliée) de l’Internet d’aujourd’hui.
Le DNS va permettre à l’internaute de renseigner dans son navigateur web, un nom de domaine pour accéder à un site web. Le navigateur va alors « résoudre » ce nom de domaine pour obtenir l’adresse IP du serveur web qui héberge ce site web et l’afficher. On appelle ça la « résolution DNS ».
Pierre angulaire du web, si le DNS tombe, vos sites web et vos e-mails tombent, ce qui de nos jours est purement impensable. D’autres applications peuvent être impactées dans les entreprises : l’accès au VPN, intranet, cloud, VOIP… tout ce qui nécessite potentiellement une résolution de noms vers des adresses IP. Le DNS doit donc être protégé et rester hautement disponible.
Si le protocole DNS a été conçu avec un souci de la sécurité, plusieurs failles de sécurité du protocole DNS ont été identifiées depuis. Les principales failles du DNS ont été décrites dans le RFC 3833 publié en août 2004. Interception de paquets, fabrication d’une réponse, corruption des données, empoisonnement du cache DNS et Déni de service. Je vous renvoie à l’article français de Wikipedia sur le sujet, fort bien documenté.
Pour contrer ces vulnérabilités, le protocole DNSSEC a été développé.
DNSSEC permet de se prémunir de ces différents types d’attaques, en particulier l’empoisonnement du cache, en assurant l’intégrité de la résolution DNS. Les enjeux de DNSSEC ont donc été les suivants :
Pour assurer l’intégrité de la résolution DNS, DNSSEC permet d’établir une chaine de confiance qui remonte jusqu’à la racine du DNS (serveur DNS racine du schéma ci-dessus). La sécurité des données est effectuée à l’aide d’un mécanisme de clés (KSK pour Key Signing Key & ZSK pour Zone Signing Key) qui signe les enregistrements DNS de sa propre zone. Les clés publiques KSK sont alors envoyées au registre correspondant pour être archivées ; le registre étant lui-même lié via DNSSEC au serveur root, la chaine de confiance s’établit. Chaque zone DNS parente, garantit l’authenticité des clés de ses zones filles en les signant.
Sans DNSSEC Avec DNSSEC
DNSSEC intervient comme une protection indispensable pour vos noms stratégiques, qui permet de sécuriser l’authenticité de la réponse DNS. Il serait opportun d’étudier les noms qui méritent d’être protégés. Tous les TLDs ne proposent pas encore DNSSEC, voici une liste non exhaustive des principaux, liste très évolutive avec de nombreux ralliements en cours :
Extension supportant actuellement DNSSEC : .fr, .com, .be, .net, .eu, .pl, .re, .pm, .yt, .wf, .tf, .info, .li, .ch, .biz, .de, .sx, .org, .se, .nl, .in, .us, .at, .nu, .la, .ac, .cz, .me, .sh, .io, .uk, .co.uk, .me.uk, .org.uk.
Tous les news gTLDs, comme .paris, .club, .xyz, .wiki, .ink, supportent également DNSSEC.
DNSSEC est inclus sans supplément dans l’offre DNS Premium de Nameshield. Nameshield vous accompagne dans cette démarche pour la sécurisation optimale de vos actifs immatériels et gère l’intégralité du protocole DNSSEC pour vous, de la création, au stockage et au renouvellement des clés.
Ce n’est pas la seule réponse à mettre en place, le système de registry lock, le service DNS Premium, les certificats SSL sont des solutions complémentaires à étudier, que nous aurons l’occasion d’aborder dans d’autres articles ou dans les prochains nameshield.cafe.
Entre mars 2016 et mars 2017, Let’s Encrypt a émis 15 270 certificats SSL contenant le terme « PayPal » ; 14 766 d’entre eux ont été émis pour des domaines menant vers des sites de phishing. C’est le résultat de la récente analyse menée par Vincent Lynch, expert SSL.
Lynch s’est intéressé de près à ce cas à la suite d’un article très intéressant publié par Eric Lawrence (Google Chrome Security Team) en janvier 2017, le visuel ci-dessus est tiré de cet article, dénommé « Certified Malice » qui dénonçait les certificats SSL frauduleux et dénombrait alors « seulement » 709 cas pour PayPal, et bien d’autres sur toutes les plus grandes marques américaines : BankOfAmerica, Apple, Amazon, American Express, Chase Bank, Microsoft, Google…
En Janvier 2017, Google et Mozilla ont mis à jour leur navigateur avec Chrome 56 et Firefox 51, et un changement majeur est intervenu pour les internautes : l’apparition des termes « Sécurisé » ou « Non sécurisé » dans la barre d’adresse.
En 2015, l’initiative Let’s Encrypt, supportée par les grands noms de l’internet (EFF, Mozilla, Cisco, Akamaï…) voyait le jour avec pour objectif de diffuser en masse et gratuitement des certificats SSL au monde entier. Un an et demi plus tard, Let’s Encrypt a délivré des millions de certificats, et d’autres initiatives de ce type ont suivi.
Qui dit gratuit, dit peu ou pas de vérification pour délivrer les certificats, et toute une armée de cybercriminels qui se sont rués vers ces certificats pour sécuriser leurs contenus illicites : phishing, malware… et afficher ainsi le terme « Sécurisé » dans leur barre d’adresse. Comment l’internaute lambda peut-il facilement différencier le vrai du faux ?
Pour mémoire, il existe trois niveaux de vérification lors de l’émission des certificats permettant d’afficher HTTPS : Domain Validation (DV) considéré comme de l’authentification faible, Organization Validation (OV) à authentification forte et Extended Validation (EV) à authentification renforcée. Les certificats gratuits sont des DV, et représentent près de 90% des certificats, la plupart du temps sur des « petits » sites web. Les certificats OV (9%) et EV (1%) sont peu nombreux mais protègent la quasi-totalité des sites web à très fort trafic. Les GAFA (Google, Apple, Facebook, Amazon) sont tous en OV ou EV par exemple.
Le problème pour l’internaute est l’absence de différenciation dans les navigateurs entre les certificats DV et OV. Ces deux types sont affichés de la même manière, étant comme « Sécurisés », alors que les certificats EV affichent le nom du titulaire dans la barre d’adresse.
En reprenant le visuel du début de cet article, on comprend aisément l’intérêt du EV pour PayPal : permettre de distinguer facilement le vrai du faux. Et c’est la raison pour laquelle Nameshield conseillera systématiquement l’emploi du EV pour les sites vitrines, en particulier pour ses clients exposés au cybersquatting, phishing ou encore contrefaçon.
Malheureusement les choses ne sont pas aussi simples et là où la logique voudrait qu’on différencie clairement les trois types de certificat, ou en tout cas au moins deux types (DV/OV), Google ne l’entend pas de cette oreille et souhaite à l’inverse supprimer cette notion d’affichage EV. Chris Palmer (Senior Software Engineer pour Chrome) le confirme à demi-mot dans son article paru ici.
Nous sommes donc aujourd’hui dans une situation où les Autorités de Certification historiques, Microsoft et dans une moindre mesure Apple, font face à Google, Mozilla et Let’s Encrypt dans une vision que l’on peut résumer comme suit :
| Vision de Google/Mozilla/Let’s Encrypt :
HTTP = Non Sécurisé HTTPS = Sécurisé |
Vision des AC historiques/Microsoft/Apple :
HTTP = Non Sécurisé HTTPS DV = pas d’indicateur dans la barre d’adresse HTTPS OV = Sécurisé HTTPS EV = Nom de la société dans la barre d’adresse |
La discussion est ouverte en ce moment même, au sein de l’instance supérieure du SSL qu’est le CAB/forum. On peut facilement comprendre que les Autorités de Certification voient d’un très mauvais œil la fin de la différenciation visuelle entre DV/OV/EV dans les navigateurs, c’est leur raison d’être de délivrer des certificats à authentification forte, mais est-ce seulement un tort ? Il s’agit quand même de rassurer l’internaute en lui garantissant l’identité du site qu’il visite.
A l’inverse, Google et Let’s Encrypt n’hésitent pas à dire que les notions de phishing et de garantie de contenu des sites web, ne sont pas du ressort des Autorités de Certification, et que d’autres systèmes existent (par exemple, Google Safe Browsing), et qu’en conséquence il faut avoir une vision binaire : les échanges sont chiffrés et inviolables (= HTTPS = Sécurisé) ou ils ne le sont pas (= HTTP = Non sécurisé). On peut simplement se demander si au travers de cette vision qui se défend également, ce n’est pas plutôt un problème de sémantique du terme employé : Sécurisé.
Que veut dire « Sécurisé » pour l’internaute ? Est-ce qu’en voyant « Sécurisé » dans sa barre d’adresse, il sera enclin à entrer ses login/password ou son numéro de carte bancaire ? On peut penser que oui et dans ce cas, le risque actuel est bien présent. Kirk Hall (Director Policy and Compliance – SSL, Entrust) a fait une intervention remarquée à la dernière conférence RSA sur ce sujet (si vous avez un peu de temps, l’enregistrement est ici).
Enfin, il ne faut pas négliger le poids de l’industrie financière ni des grandes marques qui voient d’un très mauvais œil l’augmentation du risque de fraude en ligne et que ne peut décemment pas totalement ignorer Google.
Pour le moment nous ne pouvons que vous encourager à opter pour les certificats Extended Validation pour vos sites vitrines et/ou de e-commerce afin de faciliter la tâche des internautes et à rester à l’écoute de ce qui se passe sur le web. Rassurer et éduquer également les internautes en n’hésitant pas à mentionner sur vos sites les choix que vous faites en termes de sécurité et d’authentification.
Au même titre que vous surveillez certainement les dépôts de nom de domaine sur vos marques, vous pouvez aujourd’hui également surveiller les enregistrements de certificats, et ce pour réagir rapidement.
Et en tant qu’internaute, lorsque le terme « sécurisé » est mentionné dans la barre d’adresse, systématiquement contrôlez les détails du certificat pour voir qui en est le titulaire.
Après la Belgique, l’Allemagne, les Pays-Bas, c’est au Luxembourg de subir à son tour les effets d’une attaque DDoS. Le 27 février dernier, alors que le CTIE (Le Centre des Technologies de l’Information de l’Etat) ne s’y attendait pas, plusieurs sites Internet liés au gouvernement et aux administrations nationales se sont retrouvés inaccessibles à plusieurs moments de la journée.
On se souvient que l’Allemagne et les Pays-Bas avaient subi le même genre de mésaventures début 2015. Le 4 novembre 2015, c’était ensuite la Belgique qui faisait les frais d’une attaque, revendiquée cette fois par le groupe activiste DownSec. C’est principalement le site www.wallonie.be, portail général de tous les sites officiels de la Région, qui avait été rendu indisponible à la suite de cette attaque par déni de service. D’autres attaques visant la Belgique avaient été revendiquées par le même groupement : les sites du Ministère de l’Intérieur, du Sénat, du Premier Ministre Charles Michel et du Parlement Bruxellois.
Dans le cas récent du Luxembourg, rien ne laisse penser que ce genre de groupe soit à l’origine des attaques. En effet, de nombreux hackers ont la possibilité d’attaquer les serveurs insuffisamment protégés et aucune revendication n’a été annoncée. Les motivations peuvent être tant financières que politiques ou activistes. Le CTIE de son propre aveu ne sait pas d’où vient l’attaque qui a débuté dès 9h30 le matin. Le serveur «etat.lu» a également été touché. A 10h50, le CTIE, a fait savoir via Twitter que le réseau étatique était la cible d’une attaque DDoS. Le message précisait: «Nous sommes attaqués par une DDoS et cherchons une solution». Le lendemain, l’attaque n’était pas encore terminée et une centaine de sites de l’Etat étaient encore impactés, bien que la situation soit sous contrôle.
Ce cas récent d’attaque DDoS, visant ici les institutions gouvernementales, prouve à nouveau l’absolue nécessité de considérer comme prioritaire la protection DNS, à minima sur les noms de domaine les plus stratégiques.
Le JDN vient de publier un article très intéressant sur le décollage du HTTPS sur le top 100 des sites les plus visités en France. Il en ressort que 44/100 sont maintenant en HTTPS par défaut (dont 12 dans le top 20) et 54% des pages vues sont en HTTPS. C’est une bonne nouvelle pour les internautes français MAIS…
…on peut surtout remercier les acteurs américains. Sur le top 20, le seul acteur français aujourd’hui en HTTPS par défaut est Leboncoin.fr ! Si on pousse jusqu’au top 50, on ne trouve que quatre acteurs français supplémentaires : La Poste, Le Crédit Agricole, Mappy et Service Public.fr. Sur le top 100, 44 acteurs sont en HTTPS par défaut, dont seulement 15 acteurs français. Du côté du e-commerce c’est encore pire avec 33 acteurs français dans le top 40 mais seulement 7 en HTTPS par défaut.
Google et Firefox, les deux fers de lance de la généralisation du HTTPS, continuent à annoncer des mesures toujours plus fermes en vue de l’adoption généralisée du HTTPS par défaut :
Chrome 56 arrive en Janvier 2017 avec une première série d’alertes dans les barres d’adresse pour les pages de connexion et contenant des champs de carte de crédit… et annonce déjà la couleur pour la suite avec la volonté clairement affichée d’une alerte pour tous les sites en HTTP (voir visuels ci-dessous).
Firefox n’est pas en reste et annonce la mise en place d’une alerte sur les saisies de mot de passe
Et d’autres acteurs majeurs comme WordPress, Apple ou Microsoft suivent le mouvement.
La transition d’un site Web en HTTPS par défaut n’est pas une mince affaire et deux freins importants existent encore : le risque d’un déclassement en termes de SEO si la transition est mal opérée, et certaines régies publicitaires qui restent en sources HTTP. Le trafic et les revenus publicitaires, le nerf de la guerre pour beaucoup de sites web.
Et donc, on attend ! On attend le dernier moment en espérant que Google et Firefox reculent ? C’est peu probable et le calendrier se resserre. Même si Google n’a pas encore annoncé de date pour la mise en place des alertes sur le HTTP, il y a fort à parier qu’ils le feront le plus tôt possible, et les conséquences risquent d’être désastreuses s’il faut agir dans l’urgence.
Nous recommandons d’étudier au plus tôt un calendrier de transition vers le HTTPS par défaut, projet à mener en étroite collaboration avec les équipes web et référencement, pour tous les sites vitrine dans un premier temps et pour l’ensemble des activités web dans un second.
Les équipes de Nameshield pourront vous accompagner en termes de conseil pour la mise en place et la gestion des certificats qui permettront d’afficher le HTTPS.
Estimée à 2.000 milliards de dollars d’ici 2019 [JUNIPER, 2015], la cybercriminalité est et reste un fléau important sur Internet. Elle touche de plus en plus d’entreprises. D’après Microsoft, 20 % des petites et moyennes entreprises ont fait l’objet de cybercriminalité [FORBES, 2016]. Selon ce même rapport, une majorité de ces larcins reste non détectée, notamment ceux liés à l’espionnage industriel où les données sont compliquées à récolter. En effet, on peut aisément imaginer que les entreprises touchées tardent à annoncer une brèche de sécurité, qu’elle soit d’origine logicielle ou humaine.
L’année passée, Ernst & Young publiait un rapport sur les failles et les conséquences de l’Internet des objets [EY, 2015]. Le cabinet anglais annonçait dans son étude que 56 % des entreprises n’étaient que moyennement préparées aux attaques sophistiquées :
EY proposait ainsi la création d’un département dédié au sein de chaque entreprise, selon la règle A-A-A : Activate, Adapt and Anticipate. L’étude finissait par un chiffre effarant : 58% des entreprises n’avaient pas de département spécifique, lié aux technologies émergentes et leurs impacts sur la sécurité.
Bien que le DNS ne soit pas une technologie récente, inventé en 1983 [IETF, 1983], force est de constater que même les précautions les plus élémentaires ne sont pas intégrées dans la réflexion de bon nombre d’entreprises. Réfléchir proactivement, se protéger efficacement face aux attaques usuelles de type phishing, cache poisoning, attaques DDOS,… devraient être des sujets prioritaires des entreprises dans la recherche de mise en place de stratégies de sécurité durables.
Si cette cybercriminalité existe, c’est bien qu’elle est rentable. Selon l’entreprise McAfee, elle représentait 0,64 % du PIB américain et 0,11 % du PIB français [McAfee, 2014]. Chez d’autres confrères, MarkMonitor estimait que 20 % des victimes individuelles de criminalité perdaient en moyenne plus de 1.298 USD [MarkMonitor, 2016]. Dans le cadre de cette étude, sur les 3.457 individus interrogés entre août et septembre 2016, 74 % d’entre eux exprimaient que les marques devaient avoir un programme de protection contre les fraudes afin de protéger les consommateurs et les sensibiliser face aux menaces existantes. Ainsi, même avec 87 % de gens connaisseurs des techniques de cybercriminalité, 45 % disent en avoir été victimes.
Il nous parait primordial que les marques protègent et informent leurs consommateurs : 78 % d’entre eux considèrent que les cyberattaques sur les entreprises entachent leur perception de ces dernières. Une gestion proactive des risques et menaces doit ainsi faire l’objet d’un département distinct, ou tout du moins d’une intégration dans la réflexion des collaborateurs d’une entreprise.
L’année passée, la PDG d’IBM titrait ‘la cybercriminalité est la plus grande menace pour toute entreprise dans le monde’ [Morgan, 2015]. Vous voilà prévenus.
EY, 2015. Cybersecurity and the Internet of Things, EY [en ligne], Disponible sur http://www.ey.com/Publication/vwLUAssets/EY-cybersecurity-and-the-internet-of-things/$FILE/EY-cybersecurity-and-the-internet-of-things.pdf [Consulté le 2 novembre 2016]
FORBES, 2016. Cyber Crime Costs Projected To Reach $2 Trillion by 2019, Forbes [en ligne], Disponible sur http://www.forbes.com/sites/stevemorgan/2016/01/17/cyber-crime-costs-projected-to-reach-2-trillion-by-2019 [Consulté le 2 novembre 2016]
IETF, 1983. DOMAIN NAMES – CONCEPTS and FACILITIES, IETF, [en ligne], Disponible sur https://tools.ietf.org/pdf/rfc882.pdf [Consulté le 2 novembre 2016]
JUNIPER, 2015., Cybercrime will Cost Businesses Over $2 Trillion by 2019, Juniper, [en ligne], Disponible sur https://www.juniperresearch.com/press/press-releases/cybercrime-cost-businesses-over-2trillion [Consulté le 2 novembre 2016]
MARKMONITOR, 2016. MarkMonitor ® Online Barometer Fraud and Cybercrime Survey 2016, MarkMonitor
McAfee, 2014. Net Losses: Estimating the Global Cost of Cybercrime, McAfee, [en ligne], Disponible sur http://www.mcafee.com/us/resources/reports/rp-economic-impact-cybercrime2.pdf [Consulté le 2 novembre 2016]
Morgan, S. 2015. IBM’s CEO On Hackers: ‘Cyber Crime Is The Greatest Threat To Every Company In The World’, Forbes. [en ligne] Disponible sur http://www.forbes.com/sites/stevemorgan/ 2015/11/24/ibms-ceo-on-hackers-cyber-crime-is-the-greatest-threat-to-every-company-in-the-world/ [Consulté le 2 novembre 2016]
