IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Le ministère de la Défense belge subit une cyberattaque en raison d'une vulnérabilité de Log4j,
L'identité des auteurs de l'attaque est toutefois inconnue

Le , par Bruno

73PARTAGES

12  0 
Le ministère belge de la défense a déclaré le 16 décembre avoir découvert une attaque sur son réseau informatique. L'attaque qui a eu lieu la semaine dernière en exploitant l'une des vulnérabilités de Log4j a paralysé certaines activités du ministère. « La Défense a découvert une attaque sur son réseau informatique avec accès à Internet. Des mesures de quarantaine ont été rapidement prises pour isoler les parties touchées. Cette attaque fait suite à l'exploitation de la vulnérabilité Log4j, qui a été rendue publique la semaine dernière et pour laquelle les spécialistes informatiques du monde entier s'engouffrent dans la brèche », a déclaré, Olivier Severin le porte-parole du ministère.

Depuis jeudi dernier, l'armée belge est aux prises avec les conséquences d'une grave cyberattaque. Une partie du réseau informatique ne peut être utilisée pour l'instant, précise le porte-parole. Le système de messagerie, par exemple, est en panne depuis plusieurs jours. L'attaque informatique s'est produite après qu'une faille de sécurité dans le logiciel ait été découverte la semaine dernière seulement.


Comme indiqué précédemment, l'attaque à la Défense a été causée par une faille dans la sécurité du logiciel Log4j d'Apache, largement utilisé. La faille de sécurité est apparue juste avant le week-end et représente un risque important pour les réseaux d'entreprise du monde entier, car de nombreuses applications bien connues utilisent le logiciel en question pour conserver les "journaux".

Selon le fournisseur israélien de solutions de cybersécurité Check Point Software Technologies, un groupe de pirates informatiques liés au régime iranien, surnommé Charming Kitten ou APT 35, a exploité la faille de Log4j pour lancer des attaques contre sept cibles en Israël, dont des sites gouvernementaux.

Log4j est une bibliothèque de journalisation open source basée sur Java utilisée dans des millions d'applications. Il y a quelques jours, une vulnérabilité dans Log4J a été découverte. Elle permet à un cybercriminel de provoquer une exécution de code arbitraire à distance s'il a la capacité de soumettre une donnée à une application qui utilise la bibliothèque log4j pour journaliser l'évènement.

Grâce à Log4j, les entreprises technologiques peuvent vérifier si leurs applications fonctionnent correctement. S'il y a un défaut quelque part dans une application, un message d'erreur est envoyé via Log4j au fabricant, qui peut alors déterminer si une réparation est nécessaire. Amazon, Apple, Cloudflare, Tesla, Minecraft et Twitter, entre autres, utilisent également Log4j.

L’attaque a été causée par une faille dans la sécurité du logiciel Log4j d'Apache, largement utilisé, selon le ministère de la Défense. La faille de sécurité est apparue juste avant le week-end et représente un risque important pour les réseaux d'entreprise du monde entier, car de nombreuses applications bien connues utilisent le logiciel en question pour conserver des "journaux".

La semaine dernière, des avertissements ont été lancés concernant les problèmes causés par la fuite dans le logiciel largement utilisé. Les entreprises spécialisées en cybersécurité ont indiqué que le nombre d'attaques profitant de cette faille se multiplient. Pour remédier à cette situation, les membres de l’Apache Software Fondation ont développé un patch.

Les chercheurs ont signalé qu'il existe au moins deux vulnérabilités dans le correctif, publié sous le nom de Log4J 2.15.0, et que les attaquants exploitent activement l'une d'entre elles ou les deux contre des cibles du monde qui ont déjà appliqué la mise à jour. Les chercheurs ont exhorté les organisations à installer un nouveau correctif, publié en tant que version 2.16.0, dès que possible pour corriger la vulnérabilité, qui est suivie comme CVE-2021-45046.

Le correctif précédent, ont déclaré les chercheurs, « était incomplet dans certaines configurations autres que celles par défaut » et permettait aux attaquants d'effectuer des attaques par déni de service, ce qui facilite généralement la mise hors ligne des services vulnérables jusqu'à ce que les victimes redémarrent leur serveurs ou prennent d'autres mesures. La version 2.16.0 « résout ce problème en supprimant la prise en charge des modèles de recherche de messages et en désactivant la fonctionnalité JNDI par défaut », selon l'avis de vulnérabilité lié ci-dessus.

Des chercheurs de la société de sécurité Praetorian ont déclaré qu'il y avait une vulnérabilité encore plus grave dans 2.15.0 (une faille de divulgation d'informations qui peut être utilisée pour télécharger des données à partir des serveurs concernés).

Le Centre de cybersécurité de Belgique, une organisation gouvernementale, a publié un communiqué de presse indiquant que « Les entreprises qui utilisent le logiciel Apache Log4j et qui n'ont pas encore pris de mesures peuvent s'attendre à des problèmes majeurs dans les jours et les semaines à venir. » La semaine dernière, l'Agence pour la cybersécurité et la sécurité des infrastructures (CISA) du gouvernement américain a publié une directive d'urgence exigeant que les agences fédérales prennent des mesures correctives concernant la vulnérabilité d'Apache Log4j avant le 23 décembre 2021.

Source : VRT

Et vous ?

Quel est votre avis sur le sujet ?

Voir aussi :

Jamais deux sans trois : Apache révèle un autre bogue dans la bibliothèque de journalisation Log4J, le troisième correctif majeur en dix jours est une faille de récursivité infinie

Plus de 35 000 packages Java impactés par les vulnérabilités Log4j, selon un rapport de l'équipe open source de Google

Des cybercriminels exploitent activement la faille critique dans Log4J : plus de 840 000 attaques ont été détectées, le spectre d'un scénario rappelant Heartbleed fait surface

Les cybercriminels exploitent la faille "zero-day", alors que les entreprises prennent 97 jours en moyenne pour mettre en œuvre les correctifs, selon HP Wolf Security

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Stéphane le calme
Chroniqueur Actualités https://www.developpez.com
Le 25/01/2022 à 9:00
Log4j : une entreprise du Fortune 500 exige des réponses rapides et gratuites du créateur de cURL,
qui leur a indiqué qu'il le ferait « dès que nous aurons signé un contrat de support »

Daniel Stenberg, le créateur de cURL, a reçu un courriel en provenance d'une entreprise appartenant au Fortune 500, le classement des 500 premières entreprises américaines classées selon l'importance de leur chiffre d'affaires. Ladite entreprise (ou ses clients) utilisait probablement cURL et, dans le contexte de la vulnérabilité dans la bibliothèque de journalisation Apache log4j, lui a posé une série de questions pour savoir entre autres si cURL s'appuyait sur log4j. « Si vous êtes une entreprise de plusieurs milliards de dollars et que vous êtes préoccupé par log4j, pourquoi ne pas simplement envoyer un e-mail aux auteurs OSS à qui vous n'avez jamais rien payé et exiger une réponse gratuite dans les 24 heures avec beaucoup d'informations ? » a-t-il demandé en présentant le courriel qu'il a reçu

Le 9 décembre, une vulnérabilité a été découverte dans la bibliothèque de journalisation Apache log4j. Cette bibliothèque est très souvent utilisée dans les projets de développement d'application Java/J2EE ainsi que par les éditeurs de solutions logicielles sur étagère basées sur Java/J2EE.

Log4j inclut un mécanisme de recherche qui pourrait être utilisé pour effectuer des requêtes via une syntaxe spéciale dans une chaîne de format. Par exemple, il peut être utilisé pour demander divers paramètres comme la version de l'environnement Java via ${java:version}, etc. Ensuite, en spécifiant la clé jndi dans la chaîne, le mécanisme de recherche utilise l'API JNDI. Par défaut, toutes les requêtes sont effectuées en utilisant le préfixe java:comp/env/*; cependant, les auteurs ont implémenté l'option d'utiliser un préfixe personnalisé au moyen d'un symbole deux-points dans la clé. C'est là que réside la vulnérabilité : si jndi:ldap://est utilisé comme clé, la requête va au serveur LDAP spécifié. D'autres protocoles de communication, tels que LDAPS, DNS et RMI, peuvent également être utilisés.

Ainsi, un serveur distant contrôlé par un attaquant pourrait renvoyer un objet à un serveur vulnérable, entraînant potentiellement l'exécution de code arbitraire dans le système ou la fuite de données confidentielles. Tout ce qu'un attaquant doit faire est d'envoyer une chaîne spéciale via le mécanisme qui écrit cette chaîne dans un fichier journal et est donc gérée par la bibliothèque Log4j. Cela peut être fait avec de simples requêtes HTTP, par exemple, celles envoyées via des formulaires Web, des champs de données, etc., ou avec tout autre type d'interactions utilisant la journalisation côté serveur.

La vulnérabilité a été caractérisé par Tenable comme « la vulnérabilité la plus importante et la plus critique de la dernière décennie ».

La sévérité de la brèche est maximale 10 sur l’échelle CVSS.

Des correctifs ont été proposés mais, tour à tour, il a été découvert des faiblesses dans leurs réponses. Au total, les chercheurs ont découvert quatre vulnérabilités en prenant en considération les surfaces d'attaques laissées par trois correctifs proposés pour combler la même faille.

Le créateur de cURL interrogé

cURL (abréviation de client URL request library : « bibliothèque de requêtes aux URL pour les clients » ou see URL : littéralement « voir URL ») est une interface en ligne de commande, destinée à récupérer le contenu d'une ressource accessible par un réseau informatique. La ressource est désignée à l'aide d'une URL et doit être d'un type supporté par le logiciel. Le logiciel permet de créer ou modifier une ressource (contrairement à wget), il peut ainsi être utilisé en tant que client REST.

Le programme cURL implémente l'interface utilisateur et repose sur la bibliothèque logicielle libcurl, développée en langage C. Celle-ci est ainsi accessible aux développeurs qui veulent disposer des fonctionnalités d'accès au réseau dans leurs programmes. Des interfaces ont été créées dans de nombreux langages (C++, Java, .NET, Perl, PHP, Ruby...).

La bibliothèque supporte notamment les protocoles DICT, file, FTP, FTPS, Gopher, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, POP3, POP3S, RTSP, SCP, SFTP, SMB, SMBS, SMTP, SMTPS, Telnet et TFTP.

Son créateur, Daniel Stenberg, a été contacté dans le contexte de la faille log4j par une entreprise disposant d'une capitalisation boursière lui permettant de figurer dans le Fortune 500. Dans un billet de blog, il a indiqué :

« Le vendredi 21 janvier 2022, j'ai reçu cet e-mail. J'ai tweeté à ce sujet et ça a décollé.

« L'e-mail provient d'une entreprise multimilliardaire figurant dans le Fortune 500 qui pourrait apparemment utiliser un produit contenant mon code, ou peut-être qu'ils ont des clients qui le font. Qui sait?

« Je suppose qu'ils le font pour des raisons de conformité et qu'ils ont "oublié" que leurs composants open source ne sont pas automatiquement fournis par des "partenaires" auxquels ils peuvent simplement demander ces informations.

« J'ai répondu très brièvement à l'e-mail et j'ai dit que je serais heureux de répondre avec des détails dès que nous aurons signé un contrat de support.

« Je pense que cela est peut-être un bon exemple de la pyramide open source et que les utilisateurs des couches supérieures ne pensent pas du tout à la façon dont les couches inférieures sont maintenues. Construire une maison sans se soucier du sol sur lequel se trouve la maison ».


Dans son tweet et dans son billet de blog, il supprime le nom de l'entreprise et en donne les raisons : « J'ai très probablement le droit de vous dire qui ils sont, mais je préfère quand même ne pas le faire. (Surtout si je parviens à décrocher un contrat commercial rentable avec eux.) Je pense que nous pouvons trouver ce niveau de droit dans de nombreuses entreprises ».

Et de continuer en ces termes :

« Le niveau d'ignorance et d'incompétence montré dans ce seul e-mail est ahurissant.

« Bien qu'ils ne disent même pas spécifiquement quel produit ils utilisent, aucun code avec lequel j'ai jamais été impliqué ou dont j'ai les droits d'auteur n'utilise log4j et n'importe quel débutant ou meilleur ingénieur pourrait facilement le vérifier.

« Dans la version image de l'e-mail, j'ai complété les champs de nom pour mieux anonymiser l'expéditeur, et dans le texte ci-dessous, je les ai remplacés par NNNN. (Et oui, il est très curieux qu'ils envoient des requêtes sur log4j maintenant, apparemment très tard.) »

Les courriels

Citation Envoyé par L'entreprise
Cher partenaire de l'équipe Haxx,

Vous recevez ce message car NNNN utilise un produit que vous avez développé. Nous vous demandons d'examiner et de répondre dans les 24 heures suivant la réception de cet e-mail. Si vous n'êtes pas la bonne personne, veuillez transmettre ce message au contact approprié.

Comme vous le savez peut-être déjà, une vulnérabilité zero-day récemment découverte affecte actuellement la bibliothèque de journalisation Java Apache Log4j à l'échelle mondiale, permettant potentiellement aux attaquants de prendre le contrôle total des serveurs concernés.

La sécurité et la protection des informations confidentielles de nos clients sont notre priorité absolue. En tant que partenaire clé au service de nos clients, nous devons comprendre vos plans de risque et d'atténuation de cette vulnérabilité.

Veuillez répondre aux questions suivantes en utilisant le modèle fourni ci-dessous.

1. Si vous utilisez une bibliothèque de journalisation Java pour l'une de vos applications, quelles versions de Log4j sont en cours d'exécution ?

2. Y a-t-il eu des incidents de sécurité confirmés dans votre entreprise ?

3. Si oui, quels applications, produits, services et versions associées sont impactés ?

4. Certains produits et services NNNN ont-ils été touchés ?

5. Les informations non publiques ou personnelles de NNNN ont-elles été affectées ?

6. Si oui, veuillez fournir immédiatement les détails des informations concernées NNNN.

7. Quel est le délai (MM/JJ/AA) pour terminer la correction ? Énumérez les étapes NNNN, y compris les dates pour chacune.

8. Quelle action est requise de la part de NNNN pour terminer cette correction ?

Dans un effort pour maintenir l'intégrité de cette enquête, nous vous demandons de ne pas partager les informations relatives à NNNN en dehors de votre entreprise et de réserver cette demande au personnel concerné uniquement.

Merci d'avance pour votre prompte attention à cette demande et votre partenariat !

Sincèrement,

Sécurité des informations NNNN

Les informations contenues dans ce message peuvent être CONFIDENTIELLES et sont destinées uniquement au destinataire prévu. Toute utilisation non autorisée, diffusion des informations ou copie de ce message est interdite. Si vous n'êtes pas le destinataire prévu, veuillez en informer immédiatement l'expéditeur et supprimer ce message.
Le 24 janvier, le père de cURL a reçu cette réponse, de la même adresse et elle cite sa réponse :

Citation Envoyé par Entreprise
Salut David,

Merci pour votre réponse. Êtes-vous en train de dire que nous ne sommes pas un client de votre organisation ?

/ [prénom de la personne qui s'adresse à David]
Le père de cURL a de nouveau répondu (22h29 CET le 24 janvier) à ce courriel qui l'identifiait comme étant "David". Etant donné qu'il y a une histoire à propos d'un David qui a affronté le géant Goliath, il n'a pas pu s'empêcher d'en faire une blague :

Citation Envoyé par Daniel Stenberg
Salut Goliath,

Non, vous n'avez aucun contrat établi avec moi ou toute autre personne chez Haxx à qui vous avez adressé cet e-mail, demandant beaucoup d'informations. Vous n'êtes pas notre client, nous ne sommes pas votre client. De plus, vous n'avez pas précisé de quel produit il s'agissait.

Ainsi, nous pouvons soit établir une telle relation, soit vous êtes libre de chercher vous-même des réponses à vos questions.

Je ne peux que présumer que vous avez intégré notre adresse e-mail et nos coordonnées dans vos systèmes, car nous produisons de nombreux logiciels open source largement utilisés.

Meilleurs vœux,
Daniel
Source : Daniel Stenberg (billet de blog, Tweet)

Et vous ?

Que pensez-vous de la démarche de l'entreprise du Fortune 500 ?
Que pensez-vous de la réponse de David Stenberg ?

Voir aussi :

GitHub restaure le compte du dev qui a intentionnellement corrompu ses bibliothèques, certains développeurs estiment que la suspension était déraisonnable puisqu'il s'agissait de son propre code
Log4j : la directrice du CISA s'attend à des retombées de la faille qui vont s'étendre sur des années et servir à des intrusions futures dans les systèmes des entreprises
24  0 
Avatar de vanquish
Membre expérimenté https://www.developpez.com
Le 25/01/2022 à 10:52
Je suis dans le gratuit (pas l'open source) et je suis régulièrement confronté au problème.
C'est toujours un peu désagréable mais très compréhensible.
Déjà généralement votre interlocuteur est dans la structure depuis 3 ans, alors que le produit est là depuis 15.
Il sait que c'est là, mais n'a aucune idée du modèle économique, parce que ce n'est pas son boulot et qu'il a 150 autres sous-système qu'il ne fait que superviser.

Et en vrai, c'est rarement une question d'argent.
Quand on lui explique que c'est gratuit, ça lui pose souvent un problème, car gratuit cela veux dire pas de contrat et donc personne sur qui rejeter la responsabilité en cas de problème.
Il en a, rétrospectivement, des sueurs froides.
Certains utilisateurs qui pourraient avoir le produit gratuitement préfère payer pour avoir un lien contractuel.
8  1 
Avatar de tabouret
Membre confirmé https://www.developpez.com
Le 25/01/2022 à 10:24
Quelqu'un peut m'expliquer le lien entre Curl et Log4j?

Sinon on peut aussi demander à Nespresso s'il sont sensibles à Log4j dans la foulée.
6  0 
Avatar de Escapetiger
Expert éminent https://www.developpez.com
Le 24/12/2021 à 13:34
Nous sommes dans un forum spécialisé mais tout de même pour une question de clarté avec tous ces sigles :

IPS
« Un système de prévention d'intrusion (ou IPS, intrusion prevention system) est un outil des spécialistes en sécurité des systèmes d'information, similaire aux systèmes de détection d'intrusion (ou IDS, intrusion detection system), permettant de prendre des mesures afin de diminuer les impacts d'une attaque. C'est un IDS actif, il peut par exemple détecter un balayage automatisé malveillant, et bloquer les ports.

Les IPS peuvent donc parer les attaques connues et inconnues. Comme les IDS, ils ne sont pas fiables à 100 % et risquent même en cas de faux positif de bloquer du trafic légitime.
(.../...) »

EDR
« Un logiciel de type EDR désigne une technologie émergente de détection des menaces sur les EndPoints (ordinateurs, serveurs). Ce terme Endpoint Detection and Response (EDR), est utilisé pour la première fois en juillet 2013 par Anton Chuvakin1 de la société Gartner.
(.../...)
Combiné avec un moteur basé sur de l'intelligence artificielle, le logiciel EDR est très réactif dans la détection et l'arrêt de menaces (Malwares, virus, attaques zero Day, menaces persistantes avancées, ...). L'intelligence artificielle lui permet d'être auto-apprenant et de ne pas devoir se connecter sur internet pour mettre à jour des bases de données.
»

Sources Wikipedia :

Système de prévention d'intrusion

Endpoint detection and response
5  0 
Avatar de sekaijin
Expert éminent https://www.developpez.com
Le 24/12/2021 à 16:40
Lister les dépendances par transitivité pour connaitre les projet "Potentiellement" impactés
N'est en soit pas très compliqué mais très largement insuffisant surtout si on fait ça sur maven central.
En effet Maven Central garde aussi toute les vielles versions donc même s'il y a eu des corrections les version non corrigé restent.

On peut très vite avoir des chiffres énorme sans pour autant que ce soit la cata.

Quant à ce que que j'ai lu ici sur YAKAFOKON c'est très loin d'être si facile. Je m'occupe d'un outil qui est composé de centaines d'éléments divers avec un chargement dynamique la bête a tourné 8 ans sans interruption, avec des mise à jour à chaud, un changement de serveur physique à chaud (juste des arrêts partiels de certain composants quelques minutes).
Arriver à qualifier la compatibilité de plusieurs centaines de composants est un très long travail. Il nous est déjà arrivé de revenir en arrière après plusieurs mois de travail parce qu'un composants n'était plus compatible avec l'ensemble.

Quant à l'approche de google si j'avais suivi la même approche j'aurais à ce jour environs 200 projet impactés.
Hors tous dépendent d'une librairie qui est compilé avec log4j (donc une dépendance). Mais cette librairie importe une partie seulement de log4j et supprime tout le code inutile. La partie impactée par le PB de sécurité n'est plus dans le code de la lib. les 200 projets ne sont donc pas impactés.

à contraio je suis tombé sur un dev qui importe par transitivité un clone de log4j qui lui embarque le code en question et là l'approche de Google ne l'a pas trouvé et pour cause. Ouf il s'agissait d'un démonstrateur pas de prod.

Donc à tous les YAKAFOKON Oui il est très simple dans le gestionnaire de dépendance de surcharger la version de log4j pour en choisir une non impactée.
Mais sur les millions de lignes de code comment garantir que ce changement ne va pas introduire de bug ?
On pourrait imaginer que finalement ce ne sont que des log c'est pas si grave si on n'a pas la trace tant que le prog fonctionne mais voilà un changement de version de log4j sans précaution et up un nullpointerexception dans un log.info et le prog ne fonctionne plus.

Il n'y a rien de simple. C'est un travail permanent, une vigilance, et des mois de tests pour valider un assemblage.

A+JYT
5  0 
Avatar de gabriel21
Membre expérimenté https://www.developpez.com
Le 25/01/2022 à 11:36
Le mail ressemble beaucoup à des mails que je peux voir passé en interne ou du client quand le service SSI panique et comme il savent pas où ils habitent, ni ce que font les administrateurs et les développeurs, ils leurs posent la totalité des questions que le RSSI ou tout autre directeur leur a posé.
L'affaire est cocasse, surtout la réponse... Ah bon, vous ne travaillez pas pour nous...
Il s'agit là plus d'une incompétence personnel que d'une société, même si l'ultra procéduralisation et les équipes aux périmètres restreints et hermétiques peuvent être la cause profonde de ce genre de situation.
J'ai par exemple eu le cas d'une demande pour savoir si on avait bien patché une vulnérabilité noyau Windows sur nos serveurs applicatifs qui tournaient sur RHEL et AIX....
Des perles de ce type, j'en vois malheureusement très souvent.
5  0 
Avatar de TJ1985
Membre expérimenté https://www.developpez.com
Le 14/01/2022 à 9:34
C'est ce qui m'a toujours effrayé lorsque j'ai assisté à l'explosion des bibliothèques et plateformes en ligne. Pour avoir commis une fois un bug dans une librairie partagée, je mesure pleinement l'impact que ça peut avoir. Là, j'avais encore la main dessus, et sur l'ensemble des applications qui l'utilisaient et ça a quand même fait des dégâts. Mais si elle avait été lâchée dans la nature... à moi la peur !
J'ai l'impression que nous avons perdu la tête. Toutes les entreprises ne font pas du commerce en ligne, toutes n'ont pas besoin d'un cloud externe et beaucoup bénéficieraient des services d'un bon analyste bien plus que d'une SSII avide de rentabilité - pour elle-même.
5  1 
Avatar de dolu02
Membre averti https://www.developpez.com
Le 25/01/2022 à 10:47
Citation Envoyé par walfrat Voir le message
Personnellement je demande a voir la fin de l'histoire avant de basher la société.

Le premier mail de la société peut paraître agressif et stupide mais ça peut ni plus ni moins venir de personnes qui font ce genre de mail aussi bien à des sociétés privés sous contrat qu'a des gens du monde open source sans contrat, car ils ignorent la différence.

En outre le second mail de la société me paraît être un signe qu'ils sont pas si mal tombé.
C'est justement ce qui leur est reproché, d'être ignorants. S'ils ont des IT en interne (on peut le supposer pour une telle entreprise), pourquoi ne pas leur demander ce qu'il faut faire?
5  1 
Avatar de valtena
Membre confirmé https://www.developpez.com
Le 26/01/2022 à 15:06
Citation Envoyé par AoCannaille Voir le message
Le ton n'est pas arrogant, le mail est lisse, factuel et surtout impersonnel. En un mot : Une communication Professionnelle. Si tu trouve ce mail arrongant, j'espère que tu ne travaille pas dans des grosses boites car c'est tout simplement la seule méthode qu'ils ont pour communiquer par écrit.
Le mail arrive avec pas mal d'impératif. Quand tu lis la tournure du mail la réponse est due. C'est assez arrogant en dehors d'un lien de subordination. Qu'il soit lissé et automatisé n'enlève rien à la chose.
5  1 
Avatar de marsupial
Expert confirmé https://www.developpez.com
Le 25/01/2022 à 12:08
Disons qu'il s'agit d'une entreprise qui fait une crise salutaire de parano dans le contexte cybersécuritaire actuel où la Maison Blanche a donné l'ordre à l'administration de bien vérifier la chaîne d'approvisionnement. A mon avis cette organisation a du faire la même demande à tous ses fournisseurs IT. Pour moi, il s'agit d'une démarche allant dans le bon sens. Le dialogue ne doit pas être rompu entre les deux parties évoquées pour déboucher sur une solution amiable. En tout cas, j'ai souri tant à la nouvelle qu'à certain commentaires.
3  0