Analyse comparative des domaines de premier niveau, les fameux Top Level Domains (.com, .fr…)
Le nerf de la guerre des sites web à forte visibilité est le temps de téléchargement. Facteur de référencement naturel admis par Google, ce temps de téléchargement peut être impacté significativement lors de la résolution DNS. S’il convient de s’appuyer sur une infrastructure DNS de premier ordre, le choix de l’extension associée à un nom de domaine a son importance. En effet, les registres ne sont pas tous aussi performants les uns que les autres en matière de DNS, pour ne pas dire que certains affichent des performances décevantes. L’offre en matière de TLD (près de 1400) a largement augmenté depuis le programme des nouvelles extensions de l’ICANN. Analyse à suivre.
Petit retour sur le temps de résolution DNS et son impact sur le temps de chargement
La résolution d’un domaine tel que nameshield.net suit plusieurs étapes avant de pouvoir contacter le serveur de contenu. Le résolveur DNS contacte les serveurs DNS racines (.), puis les serveurs DNS du registre de l’extension concernée (.net) afin d’obtenir la liste des serveurs DNS responsables du domaine, et enfin ces serveurs DNS pour obtenir la réponse demandée. La réponse obtenue est certes mise en cache par le DNS résolveur (généralement géré par le FAI), mais ce ne sera pas toujours le cas en fonction de la popularité de votre domaine.
Cela signifie que si le DNS du domaine de premier niveau (.net) est lent, il peut en fait retarder la résolution DNS pour le domaine lui-même et, dans le pire des cas très improbable, même provoquer une panne. Vous ne pouvez pas y faire grand-chose à part bien choisir le fameux TLD.
Analyse comparative
Bunny CDN, un acteur slovène de la livraison de contenu a mené la surprenante analyse suivante. S’appuyant sur leur réseau mondial, ils ont surveillé les performances DNS dans le monde entier à partir de plus de 50 sites et réseaux.
Pour chaque domaine de premier niveau, leur système a choisi un serveur de noms aléatoire publié pour chacun des domaines de premier niveau et a interrogé un nom de domaine également aléatoire. Les résultats ont été groupés par région et les données enregistrées toutes les 10 secondes.
Résultats
Ils ont testé 42 des domaines de premier niveau les plus populaires, puis agrégé les résultats en une moyenne médiane mondiale et une agrégation à 85 centiles (les 15% de réponses les plus lentes n’ont pas été prises en compte). Ces tests ont été effectués uniquement à partir de leur réseau, une étude plus complète mériterait certainement d’être menée, mais ils offrent un bon aperçu général.
Des résultats ont été assez surprenants
Les domaines les plus étonnants concernent les .info et .org qui ont montré des performances vraiment médiocres, en particulier dans la plage de 85 centiles, et ce malgré leur ancienneté et les millions de domaines enregistrés. Il semble que 4 des 6 serveurs de noms fonctionnent extrêmement mal, ce qui explique les mauvais résultats.
Le .net et le .com ont été très légèrement plus lents qu’attendu en Europe et en Amérique du Nord, mais offrent par ailleurs des performances excellentes et stables dans toutes les régions, visibles dans la médiane mondiale. Le .net et le .com ont des réseaux beaucoup plus grands, mais restent un choix très intéressant pour obtenir les performances maximales absolues.
Moins attendue, la performance des TLD .co, .biz et .in, bien en avance sur les autres.
Certains nouveaux domaines (.online, .top, .blog…) attirants sur le plan marketing et en forte croissance, montrent des performances décevantes…
… à l’inverse de très bonnes surprises pour .live, .email, .news, gérés par Donuts Inc ou encore .club et .buzz gérés par Neustar Inc, avec cependant une très forte baisse des performances dans des régions en dehors de l’Europe et de l’Amérique du Nord, ce qui aggrave encore le problème.
42 TLD parmi les plus populaires des 1400+ disponibles ont été testés. Sans tirer de conclusion définitive, nous pouvons supposer que beaucoup pourraient ne pas fonctionner beaucoup mieux.
Conclusion
Faut-il révolutionner la gestion de votre portefeuille de noms de domaine et le choix des TLD pour vos sites les plus visibles ? Faut-il tout passer en .biz ou en .co immédiatement pour augmenter les performances ?
Certainement pas. Tout d’abord, les réponses DNS sont fortement mises en cache, en particulier pour les sites Web très populaires, les résolveurs peuvent ne pas avoir besoin de toucher beaucoup de serveurs de noms de niveau supérieur. Ensuite, le choix d’un nom de domaine répond avant tout à des impératifs marketing (marque, zone géographique, disponibilité du nom) souvent bien plus impactants que les 50 millisecondes supplémentaires de temps de chargement pour le chargement de la première page.
Cependant, si vous essayez de comprimer absolument tous les derniers bits de performances et d’assurer une grande fiabilité dans un système où chaque dernière milliseconde compte, alors vous voudrez peut-être réfléchir à deux fois avant de choisir votre domaine. Les différences ne sont pas énormes, mais si vous visez à atteindre ce temps de chargement d’une seconde, les choses s’accumulent, dans certains cas, jusqu’à 200 ms.
Bien choisir son TLD en fonction des performances DNS certes, mais probablement pas de quoi s’en inquiéter trop.
Let’s Encrypt a récemment
fait parler dans le petit monde des certificats TLS, en révoquant soudainement 3 048 289
certificats qui n’auraient pas dû être délivrés. Un bug dans leur logiciel de
validation empêchait les contrôles des enregistrements CAA, et les certificats
en question n’auraient pas dû être initialement délivrés. Des perturbations
importantes ont résulté de cette révocation massive, mais il est difficile de
se plaindre d’un service gratuit.
On me demande souvent ce que je
pense de Let’s Encrypt, et j’ai toujours cette même réponse : Let’s
Encrypt a fait énormément pour chiffrer le web, mais met à mal la sécurité du
web. Le chiffrement permet d’assurer la confidentialité (personne ne peut
espionner) et l’intégrité (personne ne peut modifier) des échanges. Mais le
chiffrement seul ne peut suffire si je n’ai aucune garantie de
l’identité de celle ou celui avec qui j’échange (légitime ou frauduleux ?)…
Et c’est bien là tout le problème.
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. Plus de cinq ans après sa
création, l’organisation sécurise 190 millions de sites web et vient d’annoncer
avoir distribué un milliard de certificats. Le cap a été franchi le 27 février
2020. C’est indiscutablement une belle performance.
96% du web chiffré en janvier 2020
En 2015, moins de la moitié du
trafic web était chiffrée, pour grimper à 96% en janvier 2020. Bien sûr Let’s
Encrypt n’est pas le seul acteur responsable de cet essor. Edward Snowden a
lancé la première alerte, Google s’est largement engouffré dans la brèche,
entre politique de référencement et modification des indicateurs de sécurité
web. Mais en mettant à la disposition de tous, des certificats gratuits et
basés sur un système largement automatisé, Let’s Encrypt a démocratisé le
chiffrement… et mis aux oubliettes la notion d’identité.
Pas d’identité, pas de sécurité
Le credo de Let’s Encrypt est la
simplicité, pour « simplifier à
l’extrême le déploiement du HTTPS et en finir avec sa bureaucratie horriblement
complexe » (dixit l’EFF dans la campagne de lancement). La bureaucratie
horriblement complexe a pourtant une raison d’être : l’authentification
forte, garante de l’identité du titulaire du certificat. Peut-être pas une
garantie absolue de légitimité, pas une garantie de contenu non plus, mais la
garantie d’une société enregistrée, légitimement propriétaire du nom de domaine
concerné et avec un certificat validé selon une procédure drastique.
Let’s Encrypt, se contente de
vérifier le contrôle du nom de domaine (DV, Domain Validation). Il suffit de
cliquer sur un lien dans un email ou de renseigner un record TXT sur la zone
DNS du nom de domaine. Or l’enregistrement de noms de domaine dans la plupart
des TLD est purement déclaratif. Il est assez facile d’enregistrer un nom de
domaine, de demander un certificat à Let’s Encrypt et de publier un site web en
HTTPS://.
Résultat des courses ?
En cinq ans, l’ensemble des sites de phishing et sites frauduleux sont passés en HTTPS://. Dès 2016, Vincent Lynch alertait sur ce problème, 15 270 certificats contenant le terme « Paypal » avaient été émis par Let’s Encrypt, dont 14 766 frauduleux.
Le marché a été tiré vers le bas
en termes de niveau d’authentification. Let’s Encrypt est loin d’être le seul
responsable, Google et Mozilla, du haut de leurs 70% de parts de marché, ayant
largement soutenu l’initiative, les gros hébergeurs du Cloud ont suivi, de même
que les Autorités de Certification, challengées sur les prix. Nous avons
aujourd’hui un web sécurisé avec 77% (novembre 2019) de certificats dont la
légitimité du propriétaire n’est pas vérifiée.
L’authentification forte change la donne
Le web est devenu chiffré par
défaut. Est-il plus sûr pour autant ? Rien n’est moins sûr. L’internaute,
éduqué depuis 20 ans à vérifier la présence du cadenas dans sa barre d’adresse,
fait confiance à un web dont tous les sites frauduleux affichent le cadenas de
sécurité. L’Internet est aujourd’hui
confidentiel, mais il n’est pas sûr pour autant.
Il est urgent de revenir à l’authentification forte. L’authentification forte garantit un ensemble d’étapes obligatoires, drastiques et contrôlées pour l’obtention des certificats. Les procédures sont édictées par le CA/B Forum, renforcées régulièrement et suivies d’audit des Autorités de Certification.
23% des certificats sont encore
délivrés sur la base de l’authentification forte, la plupart dans le monde de
l’entreprise où les RSSI poussent pour la préserver. Nous devons tous nous
appuyer sur eux, et soutenir les initiatives supportant les certificats OV
(Organization Validation) et EV (Extended Validation), en particulier EV pour
garantir l’identité des sites visités par les internautes.
Si l’identité sur Internet semble avoir été quelque
peu oubliée depuis quelques temps au profit de la confidentialité, elle risque
de revenir rapidement sur le devant de la scène, poussée notamment par les
internautes et le besoin de protection des données personnelles.
Apple a annoncé cette semaine que la durée de vie maximale des certificats SSL/TLS sur ses appareils et son navigateur Safari serait limitée à 398 jours (1 an, et 1 mois pour couvrir la période de renouvellement). Le changement, annoncé par Apple lors de la réunion CA / Browser Forum à Bratislava, en Slovaquie, entrera en vigueur pour les certificats émis après le 31 août 2020.
L’annonce d’Apple fait suite à un échec du vote du CA/B Forum sur les certificats d’un an (bulletin SC22), qui s’est tenu en août 2019, et reflète une tendance continue à raccourcir la durée de vie des certificats. A la suite de ce vote, Google avait d’ailleurs exprimé son intention de réduire la durée de vie des certificats en dehors du cadre du CA/B forum si celui-ci ne se positionnait pas rapidement. Cette annonce est une demi-surprise, nous aurions plutôt pensé que Google ou Mozilla ferait le premier pas.
Quelles conséquences pour les sociétés et leurs certificats SSL/TLS?
La validité plus courte est-elle une bonne chose?
Plus la période de validité
d’un certificat est courte, plus le certificat est sûr. En exigeant le
remplacement des certificats sur une période plus courte, les mises à jour de
sécurité sont apportées aux certificats, elles se déploient plus rapidement. La
durée de vie de la clé privée d’un certificat, plus courte, est aussi une forte
recommandation des acteurs de la sécurité en ligne afin de limiter la durée
potentielle d’une fraude suite à une compromission.
D’un point de vue sécurité,
tout le monde s’accorde à dire qu’une réduction de la durée de vie des
certificats est une bonne chose. Le problème se situe du côté opérationnel avec
les conséquences annoncées de cette réduction : plus d’interventions sur
les certificats, donc une plus grande complexité dans le maintien d’un
inventaire à jour et le besoin d’une organisation optimale avec les partenaires
pour l’émission des certificats.
Faut-il tenir compte de l’annonce d’Apple ?
Safari est l’un des deux principaux
navigateurs web, avec 17,7% en janvier 2020, derrière Google Chrome (58,2%) et
devant Microsoft Internet Explorer et Edge (7,1%). Il parait difficile de faire
fi de cette annonce qui touchera 1/5 des internautes, qui plus est si Google
suit, il vaut mieux anticiper et se préparer. C’est d’ores et déjà le conseil
de Nameshield.
Ce qu’il faut garder à l’esprit
Les certificats émis avant le 1er septembre 2020 ne sont pas affectés par cette modification. Ils resteront valides pendant toute la période de deux ans et n’auront pas besoin d’être modifiés ou remplacés. Tous les certificats émis le 1er septembre ou après devront être renouvelés chaque année pour rester fiables par Safari.
Il faut donc se préparer à
passer à des certificats d’une durée d’un an maximum contre deux actuellement.
S’appuyer sur un partenaire et des outils efficaces est plus que jamais
indispensable.
Vers la fin de la corrélation entre l’authentification et la gestion technique des certificats
Ce qui semble se dessiner au
sein du CA/B Forum est le fait de permettre une durée d’authentification
identique à celle que l’on connait aujourd’hui (deux ans) tout en forçant les
certificats à être remplacés plusieurs fois durant cette même période.
Les principales Autorités de
Certification, les organismes qui délivrent les certificats, anticipent ces
changements et travaillent sur plusieurs systèmes d’automatisation du cycle de
vie des certificats. Elles limiteraient ainsi le besoin de passer par une
procédure de réauthentification potentiellement lourde à chaque remplacement.
Les entreprises pourraient remplacer leurs certificats autant de fois qu’elles
le souhaiteraient durant cette période. Cela permettrait notamment d’anticiper
d’éventuelles nouvelles réductions de la durée de vie maximale des certificats.
La tendance est également à la
mise en place d’outils d’automatisation pour le maintien d’un inventaire précis
des certificats d’une part et la réinstallation technique de l’autre.
Nameshield suit de près ces différentes évolutions et vous permettra de
continuer à travailler en toute confiance.
Notre équipe se tient également à votre disposition pour anticiper ces changements et répondre à vos éventuelles questions.
Navigateurs et Autorités de Certification, le combat continue.
2019 fut une année bien remplie, avec un renforcement des divergences de point de vue entre fabricants de navigateurs et Autorités de Certification, l’explosion du nombre de sites de phishing chiffrés en HTTPS et l’avancée significative sur la dépréciation de TLS v1.0.
Les débats autour de la
validation étendue, plus généralement du traitement visuel des certificats dans
les navigateurs, et de la réduction de la durée des certificats ont pris une
place prépondérante. Aucune de ces conversations n’est terminée, aucun
consensus ne semble se dessiner, 2020 s’annonce comme une année chargée. Place
à l’anticipation…
Le sort d’Extended Validation sera-t-il fixé ?
2019 a vu les principaux
navigateurs cesser d’afficher la fameuse barre d’adresse en vert avec le
cadenas et le nom de l’entreprise, le tout au profit d’un affichage classique
et unique, ne tenant plus compte du niveau d’authentification des
certificats :
Les discussions sont pour autant toujours en cours au niveau du CA/B forum, comme au sein du CA Security Council. Ces deux instances de régulations des certificats chercheront en 2020 un moyen intuitif d’afficher les informations d’identité des sites Web.
Historiquement approuvé par tous,
notamment par l’industrie financière et les sites comprenant des transactions,
EV (l’acronyme pour Extended Validation) a été la cible de Google en 2019. Les
autres navigateurs, sous l’influence de Google, entre Mozilla financé par
Google et Microsoft et Opera basés sur Chromium open source, ont suivi dans
cette direction. Seul Apple continue à afficher EV.
Pour les navigateurs, la question
est de savoir si TLS est ou non le meilleur moyen de présenter les informations
d’authentification des sites web. Il semble que non. Google part du principe
que ce n’est pas aux Autorités de Certification de décider du contenu légitime
d’un site web et souhaite l’utilisation des certificats à des seules fins de
chiffrement.
Bien sûr les Autorités de Certification voient les choses différemment. Certes on peut y voir une réaction purement mercantile, les certificats EV sont bien plus chers. On peut aussi se demander l’intérêt de l’authentification au-delà du chiffrement. La réponse semble se trouver dans les statistiques ahurissantes des sites web de phishing chiffrés en HTTPS. Les navigateurs ont pour l’instant imposé un web chiffré certes… mais plus authentifié !
2020 sera donc l’année des
propositions de la part des Autorités de Certification : fournir une
meilleure authentification, en incluant les identifiants d’entité juridique, en
suivant la voie de la PSD2 en Europe… Une chose est sûre, l’identité n’a
jamais été aussi critique sur Internet et il incombe à toutes les parties
intéressées de trouver une solution, y compris aux navigateurs de trouver un
moyen d’afficher l’authentification forte des sites. A suivre…
Des certificats d’une durée plus courte : vers des certificats d’un an
825 jours, soit 27 mois ou encore 2 ans, la durée maximale autorisée actuellement pour les certificats SSL. Pour autant, depuis 2017 et une première tentative au sein du CA/B forum, l’industrie se dirige vers une réduction de cette durée à 13 mois (1 mois supplémentaire pour couvrir la période de renouvellement).
Google et les navigateurs sont revenus à la charge en 2019 avec un autre vote soumis au CA/B forum, là encore rejeté mais à une moins vaste majorité. Le marché bouge. Des acteurs comme Let’sEncrypt proposent des certificats d’une durée de 3 mois, d’autres souhaitent plutôt garder des durées longues pour éviter les surcharges d’intervention sur les serveurs. Une chose est sûre, le marché ne dispose pas encore des systèmes d’automatisation pour rendre plus simple la gestion et l’installation des certificats, un délai d’un ou deux ans supplémentaires serait sinon souhaitable, en tout cas judicieux.
Mais tout ça est sans compter sur
Google qui menace d’agir de manière unilatérale si le régulateur ne suit pas…
certainement en 2020.
De TLS 1.0 à TLS 1.3 : marche en avant forcée
Prévue pour janvier 2020, Microsoft, Apple, Mozilla, Google et Cloudflare ont annoncé leur intention de déprécier la prise en charge de TLS 1.0 (protocole créé en 1999 pour succéder au SSL 3.0, devenu fortement exposé) et TLS 1.1 (2006), tous deux en souffrance aujourd’hui d’une trop grande exposition à des failles de sécurité.
Si TLS 1.2 (2008) est toujours
considéré comme sûr aujourd’hui, le marché semble vouloir pousser rapidement
pour TLS 1.3, la version la plus récente de la norme, finalement publiée à
l’été 2018. TLS 1.3 abandonne le support des algorithmes trop faibles (MD4,
RC4, DSA ou SHA-224), permet une négociation en moins d’étapes (plus rapide),
et réduit la vulnérabilité aux attaques par repli. En termes simples, c’est le
protocole le plus sûr.
Petit problème cependant, le
passage à l’action de nombreux sites web. Début 2019, seuls 17% des sites web du
Alexa Top 100 000 prenaient en charge TLS 1.3, tandis qu’un peu moins de 23%
(22 285) ne supportaient même pas encore TLS 1.2. Si la décision de déprécier
les anciennes versions de protocole est une bonne décision, la forme adoptée
par les grands acteurs du web peut être critiquée, notamment par son caractère
unilatéral. En attendant, préparez-vous, nous y allons tout droit.
La menace de l’informatique quantique
Les entreprises parlent de plus
en plus de l’informatique quantique, y compris Google. Mais la réalité est la
suivante, alors que le quantum va avoir un impact sur notre industrie, ce ne
sera certainement pas en 2020, ni pendant au moins une décennie. Il y a encore
de nombreuses questions auxquelles il faut répondre, telles que: Quel est le
meilleur algorithme pour la résistance quantique? Personne n’a cette réponse et
tant qu’il n’y aura pas de consensus dans l’industrie, vous ne verrez aucune
solution quantique en place.
L’IoT gagne du terrain, mais le manque de sécurité continue d’être problématique
L’IoT est un succès, mais un
certain nombre de déploiements sont retardés en raison d’un manque de sécurité.
En 2020, les fournisseurs de services cloud fourniront ou travailleront en
partenariat avec des sociétés de sécurité pour fournir un approvisionnement et
une gestion sécurisés des appareils, ainsi qu’un écosystème IoT sécurisé
général, pour leurs clients.
Les cadres réglementaires pour la fabrication et les déploiements de l’IoT seront très certainement dirigés par l’UE, même si nous assisterons également à une augmentation aux États-Unis. Les attaques, les compromissions et les piratages IoT continueront, malheureusement. De plus, les normes de sécurité ne seront pas respectées et nous ne serons même pas proches d’un pourcentage plus élevé d’appareils sécurisés. Pourquoi ? Les fabricants d’équipement d’origine (FEO) ne sont toujours pas disposés à payer les coûts impliqués ou à les répercuter sur les consommateurs, de peur de perdre des ventes.
Les lois de chiffrement en Chine créeront beaucoup d’incertitude
Au cours des dernières années,
une partie de la transformation numérique du monde a entraîné la codification
des droits et restrictions des données dans des lois nationales et des
organisations régionales. PSD2, RGPD, CCPA, LPRPDE… un vrai casse-tête pour les
entreprises internationales face aux normes réglementaires et à la conformité.
Le 1er janvier 2020, la loi chinoise sur le chiffrement devait entrer en vigueur. Une donnée supplémentaire et… toujours floue pour ceux qui font des affaires en Chine. Des clarifications sont encore nécessaires sur plusieurs fronts. Par exemple, le chiffrement commercial des sociétés internationales doit être approuvé et certifié avant de pouvoir être utilisé en Chine – mais ce système de certification n’a pas encore été créé. De même, il existe une incertitude concernant le séquestre clé et les données qui doivent être mises à la disposition du gouvernement chinois. Cela a conduit à une vague de spéculations, de désinformation et, finalement, de réactions excessives. Compte tenu de l’opacité des parties de la nouvelle réglementation, de nombreuses entreprises optent pour une approche attentiste. Il s’agit d’une tactique judicieuse, en supposant que votre organisation ne dispose pas d’un expert juridique chinois expérimenté.
En conclusion, l’industrie des certificats continue sa mue. L’équipe certificats de Nameshield se tient à votre disposition pour aborder tous ces sujets.
Les sociétés de services financiers sont particulièrement touchées par les cyberattaques. Elles détiennent une mine d’informations sur les clients, protègent leur argent et fournissent des services essentiels qui doivent être disponibles jour et nuit. Elles constituent une cible lucrative. Parmi les angles d’attaques privilégiés : le DNS.
Le rapport annuel Global DNS Threat d’Efficient IP montre
une progression constante du nombre d’attaques sur le DNS et des impacts
financiers, avec une perte financière moyenne de 1,2 million d’euros sur
l’année 2019. Ce montant était estimé à 513 000 € en 2017 et 806 000
€ en 2018.
Si tous les secteurs d’activités sont touchés par les attaques,
82% des sociétés interrogées ont été touchées et 63% ont subi une interruption
de trafic, le secteur financier paie un tribut plus important avec 88%
d’impact. Menée auprès de 900 personnes de neuf pays d’Amérique du Nord,
d’Europe et d’Asie, l’étude indique que les établissements financiers ont subi
en moyenne 10 attaques au cours des 12 derniers mois, soit une augmentation de
37 % par rapport à l’année dernière.
La hausse des coûts n’est que l’une des conséquences des
attaques DNS pour le secteur des services financiers. Les impacts les plus
courants sont les temps d’arrêt des services cloud, rencontrés par 45% des
organisations financières, et les temps d’arrêt des applications internes
(68%). En outre, 47 % des établissements financiers ont été victimes
d’escroqueries par le biais d’attaques phishing ciblant le DNS.
L’enquête montre clairement l’insuffisance des mesures de
sécurité mises en place pour la sécurisation du DNS. Le retard dans
l’application des correctifs de sécurité constitue un problème majeur pour les
organisations du secteur. En 2018, 72% des entreprises interrogées admettaient
un délai de trois jours nécessaires pour installer un correctif de sécurité sur
leurs systèmes, durant lesquels ceux-ci ont été exposés aux attaques.
Seules 65% des institutions financières utilisent ou
envisagent d’intégrer une architecture DNS de confiance, elles semblent
toujours être en retard et ne pas prendre suffisamment conscience des risques
liés à ce point central de leur infrastructure. L’évolution des menaces sur le
DNS est permanente, les attaques nombreuses et complexes. Il convient de réagir
rapidement pour mieux se protéger.
Industrie, commerce, médias, télécoms, santé, éducation, gouvernement, service… autant d’autres secteurs touchés par les attaques. Des solutions existent. L’ANSSI publie chaque année le guide des bonnes pratiques en matière de résilience du DNS, détaillant de nombreuses recommandations pour être protégé. S’appuyer sur un réseau Anycast ; disposer de système de protection contre les attaques DDoS ; avoir du monitoring de trafic DNS et une équipe en mesure d’intervenir rapidement ; disposer d’une politique de sécurité efficace… Autant de mesures indispensables à la résilience et l’efficacité du réseau DNS face à ces attaques préjudiciables en termes d’impact financier et d’image. En espérant voir enfin de meilleurs chiffres sur le rapport 2020.
Les acteurs de l’industrie envisagent de réduire la durée de vie des certificats SSL/TLS, permettant l’affichage du HTTPS dans les navigateurs, à 13 mois, soit environ la moitié de la durée actuelle de 27 mois, afin d’améliorer la sécurité.
Google, via le CA/Browser Forum a en effet proposé cette
modification, approuvée par Apple et une autorité de certification, la rendant
éligible au vote. Si le vote est accepté lors des prochaines réunions du CA/B
Forum, la modification des exigences entrera en vigueur en mars 2020. Tout certificat délivré après la date d’entrée en
vigueur devra respecter les exigences de la période de validité abrégée.
L’objectif de cette réduction est de compliquer la tâche des cyber-attaquants en réduisant la durée d’utilisation des certificats potentiellement usurpés. Cela pourrait également obliger les entreprises à utiliser les algorithmes de chiffrement les plus récents et les plus sécurisés disponibles.
Si le vote échoue, il n’est pas à exclure que les
navigateurs parrainant cette exigence l’implémentent de manière unilatérale
dans leur programme racine, forçant ainsi la main aux autorités de
certification. Il y a fort à parier que ce soit le chemin suivi, ce changement
fait suite à l’initiative précédente de Google visant à réduire la durée de vie
de trois à deux ans en 2018, époque à laquelle Google souhaitait déjà une durée
réduite à 13 mois voire moins.
Qui est touché ?
Les modifications proposées par Google auraient une
incidence sur tous les utilisateurs de certificats TLS de confiance publique,
quelle que soit l’autorité de certification qui émet le certificat. Si le vote
passe, tous les certificats de confiance émis ou réémis après mars 2020 auront
une validité maximale de 13 mois. Les entreprises utilisant des certificats
dont la période de validité est supérieure à 13 mois seront encouragées à
revoir leurs systèmes et à évaluer l’incidence des modifications proposées sur
leur déploiement et leur utilisation.
Les certificats TLS émis avant mars 2020 avec une période de
validité supérieure à 13 mois resteront fonctionnels. Les certificats non-TLS
public, pour la signature de code, le code privé TLS, les certificats clients,
etc… ne sont pas concernés. Il ne sera pas nécessaire de révoquer un certificat
existant à la suite de la mise en place de la nouvelle norme. La réduction
devra être appliquée lors du renouvellement.
Qu’en pensent les acteurs du marché ?
Il s’agirait d’un changement global du secteur, qui aurait
des répercussions sur toutes les autorités de certification. Celles-ci voient
cette proposition d’un mauvais œil. On peut y voir avant tout un intérêt
économique mais pas uniquement…
Leur argument principal est que le marché n’est pas encore
prêt en termes de système d’automatisation des commandes et installations de
certificats. De fait les interventions humaines seraient plus nombreuses, avec
les risques associés à une mauvaise manipulation, ou tout simplement un risque
plus élevé d’oubli de renouvellement d’un certificat.
Pour les autorités de certification, réduire à si court
terme la durée des certificats présente surtout une augmentation significative
des coûts humains liés à la gestion du portefeuille de certificats. Si elles ne
sont pas fondamentalement contre cette décision, elles voudraient surtout des
délais un peu plus long pour étudier notamment ce qu’en pensent les
utilisateurs et les entreprises.
La position des fabricants de navigateurs ?
Que ce soit Google ou Mozilla, fers de lance de l’adoption
massive du HTTPS natif pour tous les sites web, et supporters de l’initiative
Let’sEncrypt, l’important c’est le chiffrement de tout le trafic web. Une
réduction de la durée des certificats réduit le risque d’usurpation des
certificats sur une longue durée et favorise l’adoption massive de systèmes de
gestion automatisés. Pour ces deux acteurs, un monde idéal contiendrait des
certificats d’une durée maximale de 3 mois. S’ils sont à l’écoute du marché
pour ne pas imposer trop rapidement leurs vues, il y a fort à parier qu’à long
terme la durée de vie des certificats continuera à diminuer.
L’avis de Nameshield
Le marché poursuit son évolution vers des durées de
certificats de plus en plus courtes, tout comme une diminution continuelle des
niveaux d’authentification et en conséquence un besoin qui va aller croissant
pour des solutions de gestion automatisées. Nous nous alignerons sur ces
impératifs et conseillons à nos clients de se préparer à cette diminution qui
arrivera, à n’en pas douter. Nos autorités de certification partenaires
suivront également cette évolution et permettront d’offrir tous les systèmes
d’inventaire permanent et d’automatisation requis.
Être entendu
Le forum CA/Browser accepte les commentaires de participants extérieurs et toutes les discussions sont publiques. Vous pouvez soumettre vos commentaires directement à la liste de diffusion du Forum : https://cabforum.org/working-groups/ (en bas de page). Nameshield est en contact avec des participants du CA/B forum et vous tiendra informés des décisions à venir.
Plus intuitive, plus complète, plus jolie… la nouvelle interface SSL de Nameshield arrive le jeudi 13 juin, pour vous permettre de gérer l’ensemble de vos certificats.
Vous disposerez maintenant d’indicateurs clés sur votre portefeuille de certificats, de différentes vues de consultation des certificats (ensemble du portefeuille, vue détaillée, certificats proches de l’expiration, commandes en cours, certificats expirés ou révoqués), d’un système de gestion des Organisations et Contacts et d’un système de commande repensé.
Enfin, un outil d’aide à la décision a été intégré pour vous aider dans le choix du bon certificat en cas de doute.
La gamme de certificats est mise à jour, à disposition les certificats SSL, RGS, Code Signing, Individuels, tous types et tous niveaux d’authentification.
L’équipe SSL se tient à votre disposition pour une démonstration, un guide complet d’utilisation est à votre disposition pour l’ensemble des opérations et actions disponibles. Contactez-nous directement sur certificats@nameshield.net.
Les acteurs et fournisseurs de
services publics envahissent le monde connecté, profitant des innovations que
le reste du monde met si opportunément à leur disposition. Ce ne serait pas un
problème si nous ne vivions pas dans une époque où le piratage d’une centrale
électrique était devenu possible.
En 2015 et 2016, des pirates informatiques ont coupé le courant à des milliers d’utilisateurs en plein hiver ukrainien. Depuis, le gouvernement américain a admis ouvertement que des puissances étrangères tentaient chaque jour de prendre le contrôle des salles de commande du réseau énergétique des États-Unis. Et c’est important parce que nous sommes actuellement en train de connecter des infrastructures vieilles de plusieurs décennies dans un environnement qui nage avec des menaces contre lesquelles elles n’ont jamais été conçues.
Les ingénieurs et informaticiens n’ont pas toujours été sur la même longueur d’onde. Ces disciplines sont différentes, ce sont des mentalités différentes ayant des objectifs différents, des cultures différentes et, bien sûr, des technologies différentes. Les ingénieurs peuvent anticiper les accidents et les défaillances, tandis que les professionnels de la cybersécurité anticipent les attaques. Il existe des normes industrielles extrêmement différentes pour chaque discipline et très peu de normes pour le domaine en plein essor de l’Internet des objets (IoT), qui se faufile de plus en plus dans les environnements des services publics. Ces deux mondes entrent maintenant en collision.
Une grande partie de
l’informatique utilisée dans l’infrastructure des services publics était auparavant
isolée et fonctionnait sans crainte des pirates informatiques, avec des
systèmes conçus pour la disponibilité et la commodité, et non pour la sécurité.
Leurs créateurs n’envisageaient pas qu’un utilisateur ait besoin de s’authentifier
sur un réseau pour prouver qu’il était digne de confiance. Et, si ce postulat
était acceptable par le passé, nous avons aujourd’hui un paysage encombré de
machines obsolètes, chargées de codes peu sécurisés et non équipées pour faire
face aux menaces informatiques modernes. La mise à niveau de ces systèmes et la
sécurité après coup, ne résoudront pas tous ces problèmes de sécurité, et les
remplacer entièrement serait bien trop coûteux, difficile à envisager et
presque utopique pour beaucoup. Et c’est un réel problème aujourd’hui que de
les connecter dans un environnement exposé à des menaces et des adversaires sans cesse à la
recherche de la prochaine cible facile.
Aujourd’hui, le monde tend à se connecter de plus en plus, notamment à travers l’Internet des objets (Internet of Things – IoT), on parle de voitures connectées, de moniteurs pour bébé connectés au smartphone d’un parent et des sonnettes qui informent les propriétaires qui se trouvent à leur porte, les frigos, les machines à laver deviennent connectés… et les services publics suivent la tendance en voulant naturellement faire partie de l’évolution de ce monde vers l’informatisation croissante des objets physiques.
Aussi passionnant que ces innovations puissent paraître, à chaque jour son lot de découverte de failles de sécurité des objets connectés. Qu’il s’agisse de mots de passe codés en dur, d’une incapacité à authentifier ses connexions sortantes et entrantes ou d’une impossibilité de mettre à jour, il y a peu d’argument concernant leur sécurité. Ces produits sont souvent précipités sur le marché sans penser à ce facteur important.
Les entreprises et les
gouvernements s’emparent de l’Internet des Objets pour transformer leur manière
de faire du business, et les services publics font de même. Les grandes infrastructures
seront de plus en plus composées de connecteurs et de capteurs IoT – capables
de relayer les informations à leurs opérateurs et d’améliorer radicalement le
fonctionnement général des services publics.
Malheureusement, dans la course à
l’innovation, les premiers arrivés ignorent souvent les problèmes de sécurité
que de nouvelles inventions brillantes apportent souvent avec elles. Et entre un
environnement industriel ou utilitaire, même si le concept d’IoT est similaire,
les impacts potentiels peuvent être radialement différents. Une poupée
connectée est une chose, une centrale électrique en est une autre !
Les risques sur les services publics, sont avérés. Il existe de nombreux exemples. Stuxnet, le virus qui a détruit le programme nucléaire iranien en est un. Les attaques susmentionnées sur le réseau électrique ukrainien pourraient en être une autre. En outre, les gouvernements occidentaux, la France y compris, admettent maintenant que des acteurs étrangers tentent de pirater leurs services publics quotidiennement.
Si c’est un si gros problème, on pourrait légitimement se demander pourquoi cela n’est-il pas arrivé plus souvent? Pourquoi n’avons-nous pas encore entendu parler d’attaques aussi dévastatrices? Le fait est que beaucoup ne savent pas qu’ils ont déjà été piratés. De nombreuses organisations passent des semaines, des mois et souvent des années sans se rendre compte qu’un attaquant se cache dans leurs systèmes. Le Ponemon Institute a constaté que le délai moyen entre une organisation atteinte et la découverte de l’attaque est de 191 jours, près de six mois donc. Cela est particulièrement vrai si l’un de ces systèmes anciens n’a aucun moyen de dire ce qui est anormal. D’autres peuvent simplement cacher leur violation, comme le font de nombreuses organisations. De telles attaques sont souvent gênantes, en particulier avec les implications réglementaires et les réactions publiques qu’une cyberattaque sur un service public entraîne.
De plus, la plupart des attaques
ne sont souvent pas catastrophiques. Ce sont généralement des tentatives pour
obtenir des données ou accéder à un système critique. Pour la plupart, c’est un
objectif suffisamment important à atteindre. S’attaquer aux possibilités les
plus destructrices d’une telle attaque constituerait essentiellement un acte de
guerre et peu de cybercriminels voudraient se mettre à dos un État.
La théorie du cygne noir – théorisée par Nassim Nicholas Taleb : une situation difficile à prévoir et qui semble extrêmement improbable, mais qui aurait des conséquences considérables et exceptionnelles – convient parfaitement ici. Nous ne savons pas quand, comment ou si un tel événement pourrait se produire, mais nous ferions mieux de commencer à nous y préparer. Même si la probabilité d’un tel événement est faible, le coût d’attendre et de ne pas s’y préparer sera quant à lui bien plus élevé. Le marché des IoT, notamment dans le secteur des services publics doit commencer à se préparer à ce cygne noir.
Les infrastructures à clés publiques (PKI) utilisant des certificats permettront aux services publics de surmonter bon nombre de ces menaces, offrant ainsi une confiance inégalée à un réseau souvent difficile à gérer. Il repose sur des protocoles interopérables et normalisés, qui protègent les systèmes connectés au Web depuis des décennies. Il en va de même pour l’IoT.
Les PKI sont très évolutives, ce qui les rend parfaitement adaptées aux environnements industriels et aux services publics. La manière dont de nombreux utilitaires vont s’emparer de l’IoT passe par les millions de capteurs qui vont restituer les données aux opérateurs et rationaliser les opérations quotidiennes, ce qui les rend plus efficaces. Le nombre considérable de ces connexions et la richesse des données qui les traversent les rendent difficiles à gérer, difficiles à contrôler et à sécuriser.
Un écosystème PKI peut sécuriser les connexions entre les périphériques, les systèmes et ceux qui les utilisent. Il en va de même pour les systèmes plus anciens, conçus pour la disponibilité et la commodité, mais non pour la possibilité d’attaque. Les utilisateurs, les périphériques et les systèmes pourront également s’authentifier mutuellement, garantissant ainsi que chaque partie de la transaction est une partie de confiance.
Les données qui circulent constamment sur ces réseaux sont chiffrées sousPKI à l’aide de la cryptographie la plus récente. Les pirates qui veulent voler ces données se rendront compte que leurs gains mal acquis sont inutiles s’ils réalisent qu’ils ne peuvent pas les déchiffrer.
Assurer davantage l’intégrité de ces données passe par la signature de code. Lorsque la mise à jour des appareils doit se faire sans fil, la signature de code vous indique que l’auteur des mises à jour est bien celui qu’il prétend être et que le code n’a pas été falsifié de manière non sécurisée depuis sa rédaction. Le démarrage sécurisé empêchera également le chargement de code non autorisé lors du démarrage d’un périphérique. La PKIn’autorise que le code sécurisé et approuvé à s’exécuter sur un périphérique, ce qui bloque les pirates et garantit l’intégrité des données requise par les utilitaires.
Les possibilités d’une attaque
contre un utilitaire peuvent parfois sembler irréalistes. Il y a quelques
années à peine, un piratage d’un réseau électrique semblait presque impossible.
Aujourd’hui, les nouvelles concernant les vulnérabilités liées à l’IoT font
régulièrement les manchettes dans le monde entier. Les implications
destructrices de cette nouvelle situation n’ont pas encore été pleinement
prises en compte, mais le fait que nous voyions des cygnes blancs ne signifie
pas qu’un cygne noir ne soit pas en train de préparer son envol.
Les utilisateurs vont commencer à
exiger de ces entreprises des dispositions de sécurité. La Federal Energy
Regulatory Commission (FERC) a récemment infligé une amende de 10 millions de
dollars à une entreprise de services publics qui a été reconnue coupable de 127
infractions différentes à la sécurité. La société n’a pas été nommée, mais des
groupes de pression ont récemment lancé une campagne, déposant une pétition
auprès de la FERC afin de la nommer publiquement avec les conséquences
potentielles sur son image de marque. En outre, avec l’avènement du règlement
général sur la protection des données (RGPD) et de la directive NIS l’année
dernière, les services publics doivent désormais examiner de plus près la
manière dont ils protègent leurs données. Partout dans le monde, les
gouvernements cherchent des moyens de sécuriser l’IoT, notamment en ce qui
concerne les risques pour la sécurité physique. La sécurité des services
publics est importante parce que les services publics jouent un rôle essentiel
dans le fonctionnement de la société. Il est tout aussi important qu’ils soient
entraînés dans le 21ème siècle, car ils en sont protégés. Les PKI offrent le
moyen de faire exactement cela.
Mike Ahmadi, vice-président de DigiCert pour la sécurité industrielle IoT, travaille en étroite collaboration avec les organismes de normalisation des secteurs de l’automobile, du contrôle industriel et de la santé, les principaux fabricants d’appareils et les entreprises pour faire évoluer les meilleures pratiques en matière de cybersécurité et les solutions de protection contre les menaces en constante évolution. L’une de ses publications est à l’origine de cet article.
C’est une question qui revient régulièrement de la part de nos clients, est-ce que l’utilisation (bonne ou mauvaise) du DNS a un impact sur le référencement naturel (SEO) des sites web ? Nous avions déjà abordé l’impact du passage d’un site web en HTTPS sur le SEO, c’est ici l’occasion de se pencher sur le côté DNS.
Le DNS est un processus invisible, implémenté à l’arrière-plan et il est difficile de concevoir en quoi cela peut aider ou nuire aux performances d’un site Web et donc au classement dans les moteurs de recherche et plus particulièrement Google.
Cet
article abordera l’impact potentiel du DNS en réponse aux questions
suivantes :
La modification d’un enregistrement DNS affecte-t-elle
le référencement ?
Le changement de fournisseur DNS
affecte-t-il le référencement ?
Quelle partie du DNS joue dans une
migration de site ?
Le changement de l’adresse IP d’un site
Web affecte-t-il le référencement du site ?
Quid de l’implémentation de
DNSSEC ?
Une panne DNS peut-elle impacter le
référencement ?
Un DNS plus rapide peut-il améliorer le
référencement ?
Le
changement au niveau DNS affecte-t-il le référencement naturel ?
1. Modification d’un enregistrement DNS, attention au TTL
La redirection d’un nom de domaine vers le serveur web correspondant passe
souvent par la création d’un enregistrement de type A (adresse IPv4). L’enregistrement
A dirigera alors le trafic vers l’adresse IP du serveur Web de destination. La
modification de cet enregistrement peut entrainer des problèmes de
performances.
En effet, pour optimiser les temps de réponses, le système DNS permet la
mise en cache des informations auprès des serveurs DNS résolveurs pour une
durée donnée, la durée du TTL (Time to live) définie par le gestionnaire
technique du nom de domaine, lors de la configuration de celui-ci. Le TTL
habituel, tel que recommandé par l’ANSSI, est de plusieurs heures pour les
utilisations classiques des noms de domaine (sites web). Dans le cas d’une
modification d’un enregistrement A, celle-ci pourrait ainsi n’être prise en
compte qu’à la fin du TTL. Les internautes pourraient donc accéder aux
anciennes configurations d’enregistrement pendant encore quelques minutes ou
même plusieurs heures après les modifications.
Il est ainsi important de réduire les
TTL, ne serait-ce que de manière temporaire lors de ces modifications.
Mais cela affecte-t-il le référencement ? Oui et non. Dans le cas d’utilisateurs envoyés vers une destination qui n’existe plus, Google considérera cela comme une erreur 404. Au-delà de l’expérience utilisateur négative, ce n’est pas directement un facteur de référencement. Attention cependant à la présence éventuelle de backlinks et d’un nombre trop important d’erreurs 404. Un TTL bas permet ainsi de limiter l’impact lors de ces modifications.
2. Modification des DNS déclarés pour un nom de domaine
Un nom
de domaine est associé à des serveurs de noms (NS / Name Servers) qui
permettent la bonne résolution DNS. Le service DNS vient chercher l’information
sur ces NS. Ces NS peuvent être modifiés lors du changement du fournisseur
gestionnaire du nom de domaine, ou simplement pour passer d’une infrastructure
DNS à une autre. Le changement de serveur de noms affectera-t-il le
référencement ?
Selon le
fournisseur et l’infrastructure choisie, les temps de résolution pourront être
plus ou moins courts avec un impact potentiel d’amélioration ou de diminution
par rapport au SERP (Search Engine Result Page). En effet, le temps de
résolution est pris en compte par Google (voir ci-après).
Et comme
pour un changement d’enregistrement, il est conseillé de réduire la durée de
vie des enregistrements avant de modifier les serveurs de nom, afin que les DNS
résolveurs ne gardent pas en cache les anciennes informations.
3. Risque lié au DNS lors de la migration d’un site
C’est le même principe qu’abordé précédemment. Les modifications des
configurations DNS n’affectent pas directement le référencement, mais elles
risquent d’entraîner une mauvaise expérience utilisateur. Il convient également
de jouer sur les TTL.
Quels cas de figure sont à considérer ?
Changer de fournisseur d’hébergement Web
Changer de fournisseur d’hébergement DNS
Déplacement du trafic de www. vers un « domaine nu » (sans le www.)
Déplacement de votre domaine vers un CDN (réseau de diffusion de contenu)
4. Changement de l’adresse IP de destination
Non. Lors de la modification d’un enregistrement pointant d’un point de
terminaison à un autre, le référencement n’est pas impacté. La seule (très
rare) exception à cette règle serait de pointer un domaine vers un point de
terminaison qui aurait déjà été identifié comme un serveur de courrier
indésirable (par exemple l’adresse IP d’un serveur mutualisé).
Attention cependant à l’adresse IP en question, une des (nombreuses) règles
de référencement de Google est qu’une adresse IP utilisée par un site web
devrait se situer à proximité de l’utilisateur final.
5. Mise en place de DNSSEC
DNSSEC permet d’authentifier la résolution DNS via une chaine de confiance entre les différents serveurs DNS de cette résolution. Comme pour le HTTPS, c’est une couche de sécurité supplémentaire à mettre en place. Comme pour le HTTPS, le temps de chargement des pages est impacté et donc potentiellement le SEO associé. Pour autant, il faut remettre les choses en perspectives, DNSSEC est indispensable à la sécurité de navigation des internautes et il est préférable de le mettre en place. La plupart des sociétés proposant des audits de sécurité autour des noms de domaine considèrent DNSSEC comme nécessaire, et donc comme un critère de notation.
Des DNS
plus rapides améliorent-ils le référencement?
Google a admis que le temps de chargement d’une page a une incidence sur les résultats du SERP. Les temps de recherche DNS sont généralement inférieurs à une seconde, ils peuvent néanmoins affecter le chargement d’une page dans les cas suivants :
1. Pannes récurrentes sur l’infrastructure DNS
Lorsque qu’un
DNS ne parvient pas à résoudre ou prend plus de temps que d’habitude, cela peut
ajouter des secondes entières au temps de chargement d’une page. En cas de
manque de fiabilité et d’indisponibilité récurrente, l’impact sur le SEO est
avéré… sans parler de l’expérience utilisateur face à des échecs répétés
(augmentation du taux de rebond, baisse de la rétention des clients et impact
sur la confiance envers la marque, voire perte de revenus). Il est important de
s’appuyer sur une infrastructure fiable et de confiance.
2. Qualité
du réseau et points de présence
C’est de
la physique pure et simple, plus un serveur de noms est proche d’un utilisateur
final, moins il faut de temps pour répondre à sa requête. Les réseaux DNS dits
« anycast » (adressage et routage optimisé vers le serveur le
« plus proche » ou le « plus efficace »), disposant de nombreux
points de présence dans le monde, permettent d’optimiser les temps de réponse en
fonction notamment de la localisation géographique.
Un autre
point important est de disposer d’au moins trois serveurs de noms qui font
autorité (SOA) pour un nom de domaine, idéalement basés sur des noms de domaine
et sur des TLDs différents, afin de réduire le risque de SPOF (Single Point of
Failure) d’une infrastructure. En effet, si une infrastructure repose sur le
même nom de domaine, une indisponibilité de ce nom de domaine, quelle qu’en
soit la raison, entraine l’indisponibilité de l’infrastructure DNS. De même au
niveau des TLDs, et même si c’est moins probable, un problème de disponibilité du registre
affecterait l’ensemble de l’infrastructure DNS.
3. Attention
aux configurations DNS « à rallonge »
Il n’est pas rare d’avoir des configurations DNS qui envoient vers une
destination finale via plusieurs étapes, comme dans l’exemple ci-dessous. Dès
lors, le temps de résolution s’en trouve impacté et potentiellement la
performance en termes de référencement naturel.
fr.wikipedia.org. IN CNAME
text.wikimedia.org.
text.wikimedia.org. IN CNAME
text.esams.wikimedia.org.
text.esams.wikimedia.org. IN A
91.198.174.232
Conclusion
Le référencement naturel est une science qu’il faut considérer dans son ensemble. Ainsi, comme nous l’avions vu au travers de l’impact du passage d’un site web en HTTPS, il s’agit d’un facteur de référencement parmi d’autres, et toutes choses étant égales par ailleurs, alors il revêt une importance particulière pour se différencier sur la première page de résultats.
Il en est de même pour l’impact du DNS sur le SEO. Le DNS peut-il avoir un
impact ? Oui, clairement dans le cas de mauvaises configurations ou
d’infrastructures DNS ne permettant pas des temps de réponses suffisamment
rapides. Une infrastructure DNS dite anycast est primordiale pour tout nom de
domaine porteur de trafic web important, qui plus est à dimension
internationale. C’est une donnée à intégrer dans un tout et il convient de
porter cette réflexion dans une approche globale du SEO avec l’équipe web
marketing.
En Septembre dernier, Accenture publiait l’étude Gaining Ground On the Cyber Attacker 2018 State of Cyber Resilience et mettait en avant le doublement du nombre de cyberattaques subies par les entreprises (en moyenne 232 en 2018 contre 106 en 2017 au plan international), mais aussi l’amélioration de la capacité des entreprises à identifier et contrer ces attaques.
Le nombre d’attaques a plus que doublé entre 2017 et 2018…
Cette étude mérite l’attention,
tant elle se différencie de nombreuses études très (trop) alarmistes. Si tout
n’est pas rose, notamment en raison de l’ingéniosité et de la complexité
croissante des attaques, les entreprises continuent à améliorer leur capacité
de défense, ont su renforcer leur cyber-résilience et sont restées performantes
malgré les menaces. Les entreprises sont de mieux en mieux capables de se
défendre, en détectant notamment les attaques beaucoup plus tôt.
… mais là où un tiers des
attaques étaient efficaces en 2017, la proportion d’attaques efficaces est
descendue à 1 sur 8 (12,5%) en 2018.
Une étude qui souffle le chaud et le froid
Les équipes de sécurité gagnent en efficacité, mais il reste encore
beaucoup à faire. Les entreprises préviennent désormais 87% de toutes les
attaques ciblées, mais subissent toujours 2 ou 3 violations de sécurité par
mois en moyenne.
Les entreprises pourraient être cyber-résilientes dans 2 à 3 ans, mais la pression et la complexité des menaces augmentent de jour en jour. Si 90% des répondants prévoient une augmentation des investissements en matière de cybersécurité au cours des 3 prochaines années, seuls 31% pensent qu’elle sera suffisante.
Les nouvelles technologies sont
essentielles, mais les investissements ont pris du retard. Si 83% des
répondants estiment que les nouvelles technologies sont indispensables,
seulement 2 sur 5 investissent dans les domaines de l’IA, du machine learning et de l’automatisation.
La confiance reste forte, mais une approche plus proactive de la cybersécurité est requise. Si plus de 80% des répondants ont confiance en leurs capacités de surveillance des violations, 71% estiment en revanche que les cyberattaques restent malgré tout un domaine assez opaque, et ne savent ni quand ni comment celles-ci pourraient affecter leur organisation.
Les Directions et Conseils d’Administration sont plus impliqués sur les enjeux de la cybersécurité. 27% des budgets de cybersécurité sont autorisés par le Conseil d’Administration, et 32% par le PDG. Le rôle et les responsabilités du RSSI (Responsable de la sécurité des systèmes d’information) doivent évoluer vers plus de transversalité dans l’entreprise.
5 pistes vers la cyber-résilience
Accenture met en avant cinq pistes
pour optimiser les défenses des entreprises et avancer vers l’objectif ultime
de la cyber-résilience dans un monde qui continue à évoluer vers de nouveaux
territoires de menaces (intelligence artificielle, omniprésence du cloud,
réseaux sociaux, smartphones, internet des objets) pour des menaces de plus en
plus complexes et difficiles à contrer et un besoin qui devient
stratégique : la protection des données.
Construire des fondations solides en identifiant les actifs de valeur, afin de mieux les protéger y compris des risques internes. Il est essentiel de s’assurer que des contrôles sont mis en place tout au long de la chaîne de valeur de l’entreprise.
Tester sa sécurité informatique en entrainant les équipes de cybersécurité aux meilleures techniques des hackeurs. Les jeux de rôles mettant en scène une équipe d’attaque et de défense avec des entraîneurs peuvent permettre de faire émerger les points d’amélioration.
Oser les nouvelles technologies. Pour une entreprise il est recommandé d’investir dans des technologies capables d’automatiser la cyberdéfense et notamment de recourir à la nouvelle génération de gestion des identités qui s’appuie sur l’authentification multi-facteur et l’analyse du comportement utilisateur.
Etre force de proposition et identifier les menaces en amont en développant une équipe stratégique (« threat intelligence ») chargée de faire évoluer un centre opérationnel de sécurité (SOC) intelligent s’appuyant sur une collecte et une analyse massive de données (« data-driven approach »).
Faire évoluer le rôle du responsable de la sécurité des systèmes d’information. Le CISO est plus proche des métiers, il trouve le bon équilibre entre sécurité et prise de risque et il communique de plus en plus avec la direction générale, qui détient maintenant 59% des budgets sécurité contre 33% il y a un an.
Conclusion
L’étude d’Accenture met en avant une vraie prise de conscience des entreprises sur les cyber-menaces, et la mise en place d’investissements de fond pour mieux se protéger. La course est maintenant lancée pour tendre vers la cyber-résilience, entre attaquants de mieux en mieux organisés et systèmes de défense de plus en plus pointus. Rendez-vous en fin d’année pour faire un bilan des forces en présence.
Nameshield utilise des cookies
Nameshield souhaite utiliser des cookies permettant d’assurer le bon fonctionnement du site et, avec nos partenaires, d’en mesurer son audience🍪.
Nameshield souhaite utiliser des cookies permettant d’assurer le bon fonctionnement du site et, avec nos partenaires, d’en mesurer son audience. Plus d'informations dans notre politique de cookies 🍪.
Ces cookies sont essentiels au bon fonctionnement du site web. Ils assurent les fonctionnalités de base et les fonctions de sécurité du site web, de manière anonyme.
Cookie
Durée
Description
cookielawinfo-checkbox-advertisement
1 year
Set by the GDPR Cookie Consent plugin, this cookie is used to record the user consent for the cookies in the "Advertisement" category .
cookielawinfo-checkbox-analytics
1 year
Set by the GDPR Cookie Consent plugin, this cookie is used to record the user consent for the cookies in the "Analytics" category .
cookielawinfo-checkbox-functional
1 year
The cookie is set by the GDPR Cookie Consent plugin to record the user consent for the cookies in the category "Functional".
cookielawinfo-checkbox-necessary
1 year
Set by the GDPR Cookie Consent plugin, this cookie is used to record the user consent for the cookies in the "Necessary" category .
cookielawinfo-checkbox-others
1 year
Set by the GDPR Cookie Consent plugin, this cookie is used to store the user consent for cookies in the category "Others".
cookielawinfo-checkbox-performance
1 year
Set by the GDPR Cookie Consent plugin, this cookie is used to store the user consent for cookies in the category "Performance".
CookieLawInfoConsent
1 year
Records the default button state of the corresponding category & the status of CCPA. It works only in coordination with the primary cookie.
Ces cookies aident à réaliser certaines fonctionnalités comme le partage du contenu du site web sur les plateformes de médias sociaux, la collecte de commentaires et d’autres fonctionnalités de tiers.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Ces cookies sont utilisés pour comprendre comment vous arrivez sur notre Site et pour mesurer le nombre de visiteurs.
Cookie
Durée
Description
_ga
2 years
The _ga cookie, installed by Google Analytics, calculates visitor, session and campaign data and also keeps track of site usage for the site's analytics report. The cookie stores information anonymously and assigns a randomly generated number to recognize unique visitors.
_gat_gtag_UA_25904574_14
1 minute
Set by Google to distinguish users.
_gid
1 day
Installed by Google Analytics, _gid cookie stores information on how visitors use a website, while also creating an analytics report of the website's performance. Some of the data that are collected include the number of visitors, their source, and the pages they visit anonymously.
CONSENT
2 years
YouTube sets this cookie via embedded youtube-videos and registers anonymous statistical data.
Ces cookies sont utilisés pour vous proposer des offres et services personnalisés, plus adaptés à vos centres d’intérêts.
Cookie
Durée
Description
NID
6 months
NID cookie, set by Google, is used for advertising purposes; to limit the number of times the user sees an ad, to mute unwanted ads, and to measure the effectiveness of ads.
VISITOR_INFO1_LIVE
5 months 27 days
A cookie set by YouTube to measure bandwidth that determines whether the user gets the new or old player interface.
YSC
session
YSC cookie is set by Youtube and is used to track the views of embedded videos on Youtube pages.
yt-remote-connected-devices
never
YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.
yt-remote-device-id
never
YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.