Archives mensuelles : avril 2020

Sauvegarde

Sauvegarde : 39 % des Français n’en font pas !

Plus d’un tiers des Français ne réalisent pas de sauvegarde, et près de la moitié parce qu’ils estiment que leurs données ou leurs fichiers ne sont pas suffisamment importants.

Un éditeur d’antivirus a réalisé une enquête en ligne dans le cadre de la Journée mondiale de la sauvegarde qui s’est tenue fin mars. Les résultats de l’enquête révèlent que, selon Avats, 39 % des Français ne sauvegardent pas leurs données ou leurs fichiers, s’exposant ainsi à une perte en cas de destruction ou de suppression. Parmi les personnes qui ne sauvegardent pas leurs données, près de la moitié (46 %) affirment ne pas disposer de données ou de fichiers suffisamment importants pour être sauvegardés. 27 % ne savent pas comment sauvegarder leurs données ; 16 % veulent le faire, mais oublient ; 11 % veulent le faire, mais n’en ont pas le temps. (Enquête en ligne menée auprès de 2 020 utilisateurs des antivirus Avast et d’AVG, du 20 février au 4 mars 2020.)

Les raisons invoquées par les propriétaires d’appareils Android et iPhone pour ne pas faire de sauvegarde sont également légèrement différentes. Les propriétaires d’iPhone semblent accorder plus de valeur à leurs données que les propriétaires d’Android. 44 % des propriétaires d’iPhone ne font pas de sauvegarde parce qu’ils pensent que leurs données ne sont pas importantes, contre 38 % des propriétaires d’Android qui partagent cette opinion. Le pourcentage de propriétaires de smartphones qui ne savent pas comment sauvegarder leurs données ne varie pas beaucoup entre les propriétaires d’iPhone et d’Android, puisque 19 % et 20 % d’entre eux, respectivement, affirment ne pas savoir comment faire.

L’étude d’Avast  indique aussi que 11 % des propriétaires d’iPhone et 19 % des propriétaires d’Android oublient d’effectuer une sauvegarde. Pour ce qui est du manque de temps à consacrer aux sauvegardes, 11 % des propriétaires d’iPhone et 16 % des propriétaires d’Android ont invoqué cette raison.

Comment optimiser la sauvegarde de ses données ?

Sauvegarder à deux endroits: lorsqu’il s’agit de sauvegarder des données, on n’est jamais trop prudent. S’il arrive quelque chose à un certain type de sauvegarde, tout pourrait être perdu. Il est donc recommandé de le faire à deux endroits différents, comme dans le cloud, et un stockage physique, comme un disque dur externe.

Déconnecter: les disques durs externes devraient être déconnectés après une sauvegarde afin de les protéger contre les logiciels malveillants tels que les ransomwares, qui peuvent se propager de l’ordinateur aux périphériques connectés.

Sauvegarder automatiquement: la plupart des services de stockage dans le cloud proposent une option de sauvegarde automatique, qu’il est conseillé d’activer, afin que les données soient automatiquement sauvegardées et sécurisées.

Le partage des responsabilités est primordial à la sécurité du cloud

« Jusqu’en 2025, au moins 99 % des incidents de sécurité liés au cloud seront imputables au client. » indiquait Gartner dans un analyse. L’entité tire ainsi la sonnette d’alarme quant à l’importance du partage des responsabilités en matière de sécurité cloud. Cet avertissement sous-entend que les organisations elles-mêmes – et non pas les fournisseurs de services cloud – doivent veiller à l’exhaustivité de leur approche en matière de sécurité.

En entreprise, la question de la migration des données sur le cloud divise l’opinion. Certains estiment que la sécurité accrue des données dans le cloud constitue l’une des principales raisons en faveur d’une migration. D’autres redoutent au contraire le manque de sécurité. Les deux parties ont en réalité raison. La sécurité constitue en effet l’aspect le plus important de l’offre d’un fournisseur de services cloud : un seul incident peut provoquer des pertes financières colossales.

Aucune organisation ne peut assumer à elle seule l’entière responsabilité de la sécurité des données. Organisations, utilisateurs, professionnels de la sécurité informatique et fournisseurs de services cloud ont pour mission commune de s’assurer que toutes les parties impliquées emploient le cloud de façon sûre.

À l’ère de l’économie numérique, la mise en œuvre d’un modèle de responsabilité est synonyme de confiance client, de risques réduits, de réputation  et plus généralement de succès opérationnel pour les entreprises.

Une clarification indispensable

Une sécurité optimale du cloud requiert plusieurs niveaux de protection. Les différents acteurs doivent s’occuper de chaque composant de la « pile des responsabilités » de façon individuelle, tout en interagissant comme une structure unifiée. Sécurité des infrastructures, contrôle du réseau, vérifications applicatives, gestion des identités et des accès, protection des terminaux, classification des données, contrôle des utilisateurs/périphériques/données, contrôle de la collaboration : la liste est longue et potentiellement effrayante pour tout service informatique, quelle que soit sa taille.

La protection proposée par les fournisseurs de services cloud ne garantit malheureusement pas une parfaite sécurité des données. Microsoft, Amazon, Google et autres grands noms précisent à juste titre que la responsabilité ne leur incombe pas entièrement et que les entreprises doivent se faire à l’idée d’une responsabilité partagée. Microsoft a par exemple publié son modèle pour Azure. Amazon applique une approche similaire pour AWS.

Dans un cas comme dans l’autre, la sécurité de l’infrastructure repose sur les actions mises en œuvre par le client afin de garantir la sécurité et la conformité du système.

Les fournisseurs de services cloud divisent traditionnellement les responsabilités en deux : ils énumèrent les fonctionnalités de sécurité proposées et laissent au client le soin de s’occuper du reste. Cette division est un bon début, mais elle peut être source d’incertitudes pour les entreprises clientes : comment déterminer et répartir les aspects relevant de leur responsabilité ? Dans chaque organisation, il est aujourd’hui indispensable de clarifier les rôles et les responsabilités de chaque acteur (sécurité informatique, risque et conformité, développeurs, acheteurs de services cloud et utilisateurs).

Cloud et location de véhicule : la responsabilité partagée de la sécurité comme point commun

La location d’une voiture illustre parfaitement le partage des responsabilités. Tout d’abord, le constructeur est dans l’obligation d’assurer que le véhicule est en état de rouler à sa sortie de la chaîne de montage. Les freins, roues et airbags doivent fonctionner comme il se doit. Une fois la voiture réceptionnée par l’agence de location, cette dernière ne vérifie pas les airbags, le locataire non plus : tous deux partent du principe que ces équipements fonctionnent correctement. Quand le véhicule n’est plus tout neuf, l’agence doit entretenir le véhicule et garantir qu’il est en état de marche.

Le locataire suppose que toutes les vérifications sur les équipements soient « ok » ; malheureusement, lorsque ce n’est pas le cas, il ne le découvre qu’au moment d’un problème avec le véhicule.

Pour les ceintures de sécurité, le principe est le même. Le constructeur doit les installer, l’agence de location les entretenir, mais c’est au conducteur qu’il revient de l’attacher et de vérifier que tous les passagers ont fait de même.

La location d’un véhicule implique ainsi une répartition des responsabilités entre cinq catégories de personnes. Chacun de jouer son rôle. Ignorer un niveau de sécurité peut avoir des conséquences désastreuses.

La responsabilité associée à la gestion des risques incombe à l’entreprise

Microsoft, Amazon et les autres fournisseurs de services cloud s’efforcent d’appliquer systématiquement des modèles de partage des responsabilités, mais les utilisateurs finaux – l’organisation en elle-même, les responsables de la sécurité des données, l’équipe de sécurité informatique, les utilisateurs – doivent assumer davantage de responsabilités.

Les dirigeants et responsables informatiques ne peuvent garantir la protection des informations dans le cloud que si les modules de sécu sont compris, en fonction et correctement mises en oeuvre !

C’est ce que démontre, depuis des semaines, des violation,  conséquence d’une mauvaise configuration des règles AWS pour des serveurs accessibles au public.

De manière générale, les responsables technologiques doivent déterminer à qui incombent la vérification et la gestion des configurations cloud, des flux de données entre différents services cloud, du comportement des utilisateurs, ou encore des contrôles relatifs à la collaboration, aux accès et aux périphériques.

Responsabilité associée

En définitive, la responsabilité associée à la gestion des risques incombe à l’entreprise, car c’est avant tout elle qui se charge de la collecte et de la sécurité.

Le fournisseur de services cloud joue certes un rôle important, mais contrairement à l’organisation cliente, il n’est pas en contact direct avec le public et n’assume pas le risque à la gestion de ces informations sensibles.

Les membres de l’équipe informatique doivent jouer le rôle de gardiens de la sécurité et de la conformité pour l’entreprise. Ils doivent travailler de concert avec le RSSI et les autres dirigeants pour comprendre et définir les politiques en matière de contrôle des données, coopérer avec les différents services pour catégoriser précisément les données, assurer la conformité réglementaire, faciliter les décisions du service des achats, définir les services cloud accessibles aux utilisateurs et garantir l’exhaustivité de la formation des utilisateurs.

En l’absence de processus stricts et de responsabilités clairement définies, une décision opérationnelle comme le déploiement d’un nouveau service de cloud public peut fortement exposer une entreprise à une violation de données ou à des incidents de sécurité connexes. À l’inverse, une démarche de partage des responsabilités permet de veiller à ce que chacun accomplisse son rôle.

Securite informatique

CDN et DDoS : Ne pas mettre tous les œufs dans le même panier

Les réseaux de diffusion de contenu, les Content Delivery Network (CDN) ont été conçus pour optimiser les performances en matière de distribution de contenus sur Internet et pour optimiser les coûts de bande passante pour celui qui produit ce contenu, afin de faire face à des demandes de plus en plus nombreuses, et à une volumétrie de données à fournir, en forte croissance. Nous entendons souvent l’argument que la protection contre les attaques DDoS fournie par un CDN est LA solution permettant de se protéger : Voyons sur quoi se base cet argument.

En simplifiant, un CDN est constitué d’un ensemble de serveurs interconnectés, largement distribués du point de vue géographique et mais aussi logique au sein du maillage de l’Internet. Le CDN utilise ces serveurs distribués pour cacher le contenu de leurs clients et le diffuser à leurs utilisateurs. Une utilisation astucieuse du routage permet de s’appuyer sur les « caches » les plus proches de chaque client, permettant une livraison plus rapide du contenu, et d’éviter ainsi de consommer des ressources – y compris la bande passante – du serveur d’origine hébergeant le contenu original.

Quand un client demande une première fois une ressource – une image ou une page web, le CDN doit chercher ce contenu auprès du serveur d’origine pour servir le client. Par contre, à partir de ce moment, la ressource reste « en cache », distribuée au sein du CDN, afin de servir toute nouvelle demande, par n’importe quel client, à partir de ces caches.

Les CDN cachent typiquement le contenu statique, qui ne change pas, comme justement les images d’un site web. Cependant, les CDN ne peuvent pas ou sont plus limités en leur capacité de cacher du contenu dynamique, comme les informations concernant les stocks et les commandes d’un site de vente.

Le contenu dynamique typiquement hébergé par le site d’origine. Le site d’origine sollicité, non pas par ses utilisateurs, mais par le CDN, d’une part pour du contenu statique pas encore caché et d’autre part pour le contenu dynamique, qui ne peut pas être caché.

CDN ET PROTECTION CONTRE LES ATTAQUES DDOS

De par sa nature, le CDN dispose des mécanismes qui peuvent être utiles en face d’attaques par déni de service distribuée. Par exemple, un CDN dispose souvent de ressources importantes en termes de capacité réseau et de serveurs, lui permettant souvent tout simplement d’absorber une quantité plus importante de requêtes que le serveur d’origine.

De plus, par les mêmes mécanismes de distribution et de routage qui lui permettent de distribuer la charge des utilisateurs, les attaques distribuées amenées à viser non plus une cible unique, mais une cible distribuée en fonction de la localisation de chaque source d’attaque.

« THE DEVIL IS IN THE DETAILS »

Par contre, malgré ces couches de protection utiles, le fonctionnement même d’un CDN peut ouvrir de nouveaux vecteurs d’attaque ou rendre la défense du serveur d’origine plus

difficile. Par exemple, si une attaque, faisant usage d’un botnet, sollicite un site web pour des ressources non-existantes, et donc non-cachées, cela peut amener le CDN à solliciter à son tour le serveur d’origine à répétition pour ces ressources et provoquer une condition de déni de service pour le serveur d’origine.

En plus, l’attaque vue par le serveur d’origine semble provenir du CDN lui même ! Dans cette situation, il peut être difficile au serveur d’origine de se protéger car le CDN est en même temps l’origine de l’attaque et des requêtes légitimes: Des approches simples s’appuyant sur le blacklisting des sources au niveau du serveur d’origine ne peuvent plus être utilisées dans ce cas.

D’autre part, il ne faut pas oublier que les protections fournies par le CDN ne couvrent que le contenu caché. Le serveur d’origine, ainsi que plus généralement, l’entreprise à qui le site appartient, aura probablement besoin d’une connectivité fonctionnelle. Au-delà du serveur d’origine qui doit pouvoir fournir le contenu non-caché et dynamique pour le CDN, le service aura peut-être besoin d’interagir avec d’autres sites, l’entreprise de pouvoir envoyer et réceptionner des emails, ses équipes d’accéder aux services de Voix sur IP ou de se connecter à Internet d’une manière générale pour accéder à des services cloud comme Google GSuite ou Microsoft Office 365.

Tout cela nécessite que des services on-site ou à minima l’accès Internet de l’entreprise, qui ne peuvent pas être protégés par un CDN, continuent à fonctionner.

Protections de type volumétriques

De plus, en fonction du CDN, les protections fournies limitées aux protections de type volumétriques, alors que des attaques applicatives plus sophistiquées risquent de traverser le CDN et d’atteindre le site d’origine. En somme, la situation est souvent bien plus complexe qu’imaginée au premier abord.

Premièrement, il est important de bien comprendre le fonctionnement, pas seulement de son site Internet, mais de son entreprise dans sa globalité et d’effectuer une analyse de risque pour identifier les différentes menaces. Ensuite, selon les risques impliquant la disponibilité et/ou la qualité de service des communications, des services réseau et/ou des applications, il peut être utile de s’appuyer sur des fonctionnalités de protection fournies par son CDN – potentiellement plus capables pour des grosses attaques volumétriques – ou utiliser des protections plutôt de type « On-Premise », potentiellement plus précises et capables pour des attaques applicatives.

Souvent une protection optimale implique une protection hybride, combinant la précision et rapidité d’une solution « On-Premise », avec des capacités volumétriques suffisamment élevés proposées par un fournisseur de service de mitigation.

Dans certains cas le CDN peut-être un composant adapté, dans d’autres vous aurez besoin d’une capacité de protection volumétrique importante capable aussi à protéger votre site local. (Par Jouni Viinikka, Directeur R&D chez 6cure ; Frédéric Coiffier, Ingénieur Développement Logiciel chez 6cure)

backdoor, Cybersécurité, IOT

NAS et Routeurs Zyxel/Linksys dans la ligne de mire de pirates

Découvertes de plusieurs cyber attaques visant les utilisateurs de stockages connectés Zyxel et routeurs Linksys.

Une ne nouvelle variante de Mirai vise les stockages connectés Zyxel.

Appelé Mukashi, ce malware utilise des attaques par force brute. Mission, s’infiltrer via différentes combinaisons d’identifiants par défaut afin de se connecter aux produits de stockage en réseau Zyxel.

Une cyber attaque qui a pour mission de prendre le contrôle et d’ajouter à un réseau de dispositifs pouvant être utilisés pour conduire des attaques DDoS.

Le PoC (proof-of-concept) de la faille CVE-2020-9054 a été rendu public en février 2019. Une vulnérabilité rapidement exploitée pour infecter des modèles NAS de chez Zyxel avec une nouvelle variante de Mirai : Mukashi. Ce code malveillant utilise la force brute pour s’infiltrer en utilisant différentes combinaisons d’identifiants par défaut, tout en informant son serveur C2 (command & contrôle) de ses réussites. De nombreux serveurs NAS de Zyxel, si ce n’est tous, utilisant les versions de firmware allant jusqu’à 5.21 sont concernés par cette vulnérabilité.

Cette vulnérabilité classée critique (c’est-à-dire un score de 9,8 selon le CVSS v3.1) en raison de son incroyable facilité d’exploitation. Faille découverte à l’origine par la vente de son code en tant que 0-day. Les pirates indiquaient que cet exploit était désormais dans les mains d’un groupe de cyber criminels qui cherchaient à l’intégrer dans l’autre code malveillant, Emotet.

Bot contre Zyxel

Mukashi est un bot qui scanne les ports 23 TCP d’hôtes au hasard. Il utilise la force brute pour s’infiltrer en utilisant différentes combinaisons d’identifiants par défaut et qui renvoie ses essais réussis vers un serveur C2. Comme les autres variantes de Mirai, Mukashi peut également recevoir des ordres de son serveur C&C et de lancer des attaques par déni de service (DoS). Une fois exécuté, Mukashi affiche le message « Protecting your device from further infections. » sur la console. Le malware change alors le nom de son processus en dvrhelper, suggérant que Mukashi a pu hériter de certaines particularités de son prédécesseur.

Avant d’exécuter son opération, Mukashi se lie au port TCP 23448 pour s’assurer qu’il n’y a qu’une seule instance tournant sur le système infecté. Le malware décode quelques chaînes de caractères à la volée lors de son initialisation. Contrairement à ses prédécesseurs qui utilisent le chiffrement xor classique, Mukashi utilise une routine de décryptage personnalisée pour chiffrer ces commandes et ces informations d’identification.

Il est indispensable de mettre à jour le firmware pour ne pas laisser entrer les attaquants. Les dernières versions du firmware sont disponibles en téléchargement. Mieux vaut utiliser des couples identifiants/mots de passe complexes pour éviter les attaques par la force brute.

Chez Linksys

Pendant ce temps, Bitdefender découvrait une nouvelle attaque ciblant les routeurs Linksys. La cyber attaque a pour mission de modifier les paramètres DNS des matériels. Mission, diriger les utilisateurs vers une page web liée au COVID-19. Une page ayant pour mission diffuser des logiciels malveillants. L’attaque a débuté le 18 mars 2020. Elle utilisait le service de raccourcissement d’adresse web TinyURL et quatre stockages Bitbucket.

Les principaux pays touchés auraient été la France, l’Allemagne et les États-Unis. 1 193 téléchargements auraient été détectées en deux jours.

Kit Covi-19 : protéger son entreprise et ses employés

Besoin d’un outil pour sécuriser vos équipes lors du confinement ? Le Kit Cyber Covid-19 a été mis en place par plusieurs entreprises Françaises, à l’initiative de ITrust.