Cliquez et faites glisser sur les ondes sonores ci-dessous pour passer à n'importe quel point. Vous pouvez également écouter directement sur Soundcloud.
Avec Paul Ducklin et Chester Wisniewski.
Musique d'intro et d'outro par Edith Mud.
Vous pouvez nous écouter sur Soundcloud, Podcasts Apple, Podcasts Google, Spotify, piqueur et partout où l'on trouve de bons podcasts. Ou déposez simplement le URL de notre flux RSS dans votre podcatcher préféré.
LIRE LA TRANSCRIPTION
[MODÈME MUSICAL]
CANARD. Bienvenue sur le podcast, tout le monde.
Je ne suis pas Douglas… Je suis Paul Ducklin.
Doug est en vacances, alors je suis accompagné de mon bon ami et collègue, Chester Wisniewski, de notre bureau de Vancouver.
Bonjour Chet !
CHET. Salut, canard.
Comment allez vous?
CANARD. Je suis très bien merci.
Nous avons eu notre première pluie dans l'Oxfordshire aujourd'hui pendant… ça doit faire au moins deux mois.
Au moins, nous avons mis un peu d'eau dans le sol, parce que c'était très, très sec ici – exceptionnellement sec.
Que diriez-vous?
CHET. Eh bien, je me remets de DEF CON malgré le fait que je n'ai pas participé à Defcon, ce que je ne savais même pas que c'était une chose.
CANARD. [RIANT] Oh, oui !
CHET. J'ai passé tout le week-end les yeux rivés sur Twitter et Twitch et Discord et toutes ces plateformes sur lesquelles on pouvait en quelque sorte pseudo-participer à distance à toutes les festivités.
Et, je dois dire que c'est beaucoup plus amusant quand on est à Las Vegas.
Mais compte tenu du nombre de personnes que je connais qui sont déjà revenues avec COVID approchent déjà plus de doigts et de pouces que moi, je pense que j'ai fait le bon choix, et je suis heureux d'être épuisé d'avoir sur-internet tout le week-end.
CANARD. Pensez-vous qu'ils ont vraiment contracté une infection à coronavirus, ou sont-ils juste revenus en se sentant, comment puis-je dire… "malade" en raison de Black Hat suivi de DEF CON.
CHET. Vous savez, aussi grave que puisse être la CON FLU…
CANARD. CONTRE LA GRIPPE ? ! [RIRES] Oh, mon Dieu !
CHET. … Je suis tout à fait convaincu que dans ce cas, c'est COVID, car non seulement les gens testent, mais pour la plupart des gens que je connais, COVID est nettement plus douloureux que même CON FLU.
Donc les deux combinés étaient probablement très horribles, je dois y penser. [RIRE]
CANARD. Oui!
Mais ne nous attardons pas sur les problèmes de coronavirus DEF CON/CON FLU…
…tournons notre attention vers une *conférence* qui a été donnée à DEF CON.
Il s'agit d'un Zoom zéro jour qui a été rédigé par Patrick Wardle et présenté à DEF CON.
Plutôt une malheureuse série de bugs, dont un qui n'a pas été correctement corrigé, Chester ?
CHET. Eh bien, Patrick n'est pas le seul chercheur en sécurité macOS au monde, mais il est assez prodigieux pour trouver des problèmes.
Et la dernière fois que j'ai vu Patrick Wardle présent, c'était à la conférence Virus Bulletin, à plusieurs reprises, et à chaque fois, il a en quelque sorte emmené Apple à l'école pour des décisions douteuses sur la vérification des signatures, la vérification des certificats, ce genre de choses.
Et je commence à avoir l’impression qu’Apple a largement façonné sa posture de sécurité autour de certaines de ces choses.
Et donc maintenant, il est à la recherche de fournisseurs supplémentaires qui pourraient commettre des erreurs cryptographiques similaires qui pourraient permettre à des logiciels malveillants d'accéder à la plate-forme.
CANARD. Je suppose qu'autrefois, tout le monde pensait : « Eh bien, tant que vous disposez d'une connexion TLS » ou « Tant que vous avez quelque chose qui est signé numériquement par *quelqu'un* ».
Ainsi, le code ne prendrait souvent pas la peine d'aller vérifier.
Mais dans ce cas, ils ont décidé de vérifier les packages de mise à jour téléchargés pour s'assurer qu'ils provenaient de Zoom.
Mais ils ne l'ont pas très bien fait, n'est-ce pas ?
Au lieu d'appeler l'API système officielle, qui s'en va, fait la vérification et revient essentiellement avec un vrai ou un faux…
… ils ont en quelque sorte « tricoté eux-mêmes », n'est-ce pas ?
CHET. Oui.
Je veux dire, tricoter vos propres choses liées à la crypto se termine toujours douloureusement.
Et je me souviens, dans le dernier podcast, vous parliez du nouvel algorithme de chiffrement quantique sûr qui a été piraté en une heure sur un ordinateur portable.
CANARD. SIKE !
CHET. Tout le monde était tellement concentré sur le côté quantique qu'ils raté le côté conventionnel, même parmi certains des mathématiciens et cryptographes les plus intelligents du monde, n'est-ce pas ?
Il est donc très facile de faire des erreurs qui peuvent être dévastatrices.
Et tricoter le vôtre est quelque chose dont vous et moi parlons, je veux dire, depuis près de 20 ans, dans différents formats de communication, au nom de Sophos.
Et je ne pense pas que nous ayons jamais changé notre position que c'est une idée terrible !
CANARD. Le problème ici n'est pas qu'ils aient décidé d'utiliser leurs propres algorithmes de signature numérique ou d'inventer leur propre courbe elliptique.
C'est juste cela, au lieu de dire : « Voici un fichier. Cher système d'exploitation, utilisez vos outils standardisés basés sur des API pour le vérifier et revenez Vrai/Faux », ont-ils choisi de débourser essentiellement…
…ils ont dirigé le pkgutil utilitaire de ligne de commande en arrière-plan, ce que vous pouvez faire à partir de la ligne de commande si vous souhaitez obtenir un affichage visuel lisible par l'homme de qui a signé quoi.
Et puis ils ont écrit un programme qui transmettrait la sortie textuelle de ceci pour décider s'ils voulaient obtenir la réponse "vrai" ou "faux".
Ils ont sorti une liste de la chaîne de certificats, et ils cherchaient "Zoom", suivi de "Developer Certification Authority", suivi de "Apple Root CA".
Alors, ils recherchent ces chaînes *n'importe où dans la sortie*, Chester !
Donc [RIRES] il s'avère que si vous avez créé un paquet qui avait un nom dans le sens de Zoom Video Communications Inc Developer ID Certification Authority Apple Root CA.pkg, puis quand pkgutil a écrit le nom du fichier dans sa sortie, les trois chaînes magiques apparaîtraient !
Et l'analyseur plutôt incompétent de Zoom déciderait que cela ne pourrait se produire que s'il avait été signé, dans le bon ordre, par ces trois organisations.
Alors qu'en fait, c'était simplement le nom que vous avez fourni.
Oh cher!
CHET. Le problème ici est que ce qui mène au problème, c'est ce genre de vérification de signature rudimentaire qu'ils font.
Mais le vrai problème, bien sûr, est que cela signifie que tout paquet pouvant recevoir ce nom sera installé * en tant que root * sur le système, même si l'utilisateur exécutant le processus de mise à jour n'est pas privilégié.
CANARD. C'était tout le problème.
Parce qu'il semblait que ce qui s'était passé, à temps pour DEF CON, Zoom * avait * corrigé ce problème.
Ils utilisent correctement l'API et vérifient de manière fiable l'intégrité et l'authenticité du fichier qu'ils sont sur le point d'exécuter.
Mais en le déplaçant dans le répertoire temporaire à partir duquel Zoom orchestre l'installation, ils l'ont laissé accessible en écriture par tout le monde !
Ainsi, le répertoire était protégé, et tout dans le répertoire était protégé… *sauf le fichier le plus important*.
Alors, devinez ce que vous pourriez faire ?
Si vous avez chronométré juste (un soi-disant condition de course), l'utilisateur d'origine pouvait modifier le fichier *après* qu'il avait réussi son contrôle d'identité numérique, mais *avant* qu'il ne soit utilisé sérieusement.
Le programme d'installation utilise un fichier qu'il pense avoir été validé, et a effectivement été validé…
… mais a été invalidé dans l'intervalle entre la validation et l'utilisation.
CHET. Oui, et comme vous le soulignez dans l'article, Canard, ce type de vulnérabilité, plutôt que d'être simplement une condition de course, est souvent appelé TOCTOU, ce qui pour moi ressemble à une sorte d'oiseau des Caraïbes.
Mais cela fait référence à un nom scientifique plus compliqué pour la faille, appelé un Heure de vérification à heure d'utilisation.
Alors, TOCTOU… "Toctou" !
CANARD. Comme toi, j'ai toujours imaginé qu'il s'agissait d'une sorte de très joli perroquet polynésien.
Mais c'est en fait, comme vous le dites, une forme laide de bogue où vous vérifiez vos faits, mais vous les vérifiez trop tôt et au moment où vous vous fiez à ces faits, ils ont changé.
Alors Zoom l'a corrigé – et Patrick Wardle a dit qu'il les félicitait… ils l'ont corrigé en un jour après qu'il ait fait le papier à DEF CON.
Ils ont correctement verrouillé les privilèges sur le fichier avant de commencer le processus de validation.
Ainsi, la validation, une fois effectuée, restait valable jusqu'à la fin de l'installation.
Problème résolu.
N'aurait-il jamais dû être là en premier lieu, n'est-ce pas?
CHET. Si vous êtes un utilisateur Mac, vous pouvez vérifier votre numéro de version pour vous assurer que vous êtes sur la version fixe.
La version corrigée est la 5.11.5 ou une version supérieure – je ne sais pas s'il y a eu des versions par la suite.
[Noter. Une autre mise à jour de la 5.11.6 est sortie entre l'enregistrement et la publication de cet épisode.]
CANARD. Maintenant, cela ne signifie pas qu'un étranger peut s'introduire dans votre ordinateur si vous n'avez pas ce correctif, mais c'est un vilain problème à avoir…
… où un escroc qui s'est introduit dans votre réseau mais qui ne dispose que, par exemple, de privilèges d'invité, peut soudainement s'élever et obtenir des super pouvoirs de root ou d'administrateur système.
C'est exactement ce que les escrocs de rançongiciels adorent faire.
Ils arrivent avec une faible puissance, puis ils progressent jusqu'à ce qu'ils soient sur un pied d'égalité avec les administrateurs système habituels.
Et puis, malheureusement, il y a très peu de limites à ce qu'ils peuvent faire de mal par la suite.
Chester, passons à la bogue suivant.
C'est un bug connu sous le nom de… eh bien, c'est A et E écrits ensemble, qui est une vieille lettre anglaise – elle n'est plus utilisée en anglais, et c'est la lettre appelée frêne, mais dans ce cas, il s'agit d'APIC/EPIC.
APIC, parce qu'il affecte les APIC, le Contrôleur d'interruption programmable avancé, et ils considèrent qu'il s'agit d'une fuite EPIC.
CHET. Je l'ai trouvé intéressant, mais commençons par le fait que je ne pense pas que ce soit aussi épique, peut-être, que son nom l'indique.
L'APIC est certainement impliqué, mais je n'en suis pas si sûr pour l'EPIC !
La vérité, lorsque vous démêlez tout cela, c'est que cela affecte une partie des processeurs d'Intel connus sous le nom de SGX, qui est le… Je vais oublier maintenant… Extensions de Software Guard, Je veux dire?
CANARD. Vous avez raison!
CHET. Eh bien, ce n'est pas le premier bogue à affecter SGX.
Je ne les ai pas tous comptés, mais j'ai trouvé au moins sept exemples précédents, donc il n'a pas eu un excellent bilan pour faire exactement ce pour quoi il est conçu.
Et la seule utilisation pratique que j'ai pu en trouver est que vous avez besoin de cette fonctionnalité pour stocker les clés secrètes permettant de lire des disques Blu-ray UltraHD sous Windows.
Et avec des puces qui ne prennent pas en charge SGX, vous n'êtes tout simplement pas autorisé à regarder des films, apparemment.
CANARD. Ce qui est ironique, car Intel a désormais, dans la 12e génération de ses processeurs… ils ont abandonné SGX pour les puces dites « clientes ».
Ainsi, les puces que vous obtenez maintenant si vous avez un tout nouvel ordinateur portable - cela ne s'applique pas, car il n'y a pas de SGX dedans.
Il semble qu'ils le voient comme quelque chose qui pourrait être utile sur les serveurs.
CHET. Eh bien, je pense qu'il est juste de dire que le sort de SGX a été scellé par Intel qui l'a déjà retiré des processeurs de 12e génération.
Si ce n'est pour le fait que c'est comme la huitième manière intelligente différente que quelqu'un a trouvée pour extraire des secrets… de la chose qui est conçue pour ne contenir que des secrets.
CANARD. Oui, c'est un rappel que la performance gêne.
Parce que je crois comprendre que la façon dont cela fonctionne est que la méthode à l'ancienne pour extraire les données du contrôleur d'interruption programmable, l'APIC, consistait essentiellement à les lire à partir d'un bloc de mémoire spécifiquement alloué à cet appareil.
Le bloc de mémoire utilisé pour les données d'interruption extraites était de 4 Ko… une page de mémoire.
Mais il n'y avait pas beaucoup de données à extraire, et ce qui s'y trouvait auparavant – par exemple, dans le cache système – a été réécrit.
En d'autres termes, le processeur d'interruption n'a pas vidé la mémoire qu'il allait utiliser avant d'écrire les octets qu'il avait l'intention de livrer.
Ainsi, parfois, il livrait accidentellement des valeurs de données à partir d'autres parties arbitraires de la mémoire auxquelles le processeur avait accédé récemment.
Et en contrôlant ce qui s'est passé et dans quel ordre, les chercheurs ont découvert qu'ils pouvaient persuader le contenu de la RAM censé être scellé dans ces "enclaves" SGX d'émerger comme une sorte de mémoire non initialisée au milieu de la gestion des interruptions.
Donc, rappelez-vous toujours que lorsque vous essayez d'accélérer les choses en prenant des raccourcis de sécurité, vous pouvez vous retrouver avec toutes sortes de problèmes.
CHET. Si vous comptez faire confiance à cette chose pour garder des secrets, elle a besoin de beaucoup de vérification.
Et on a l’impression que cette technologie SGX était à moitié cuite lors de son lancement.
CANARD. La complexité s'accompagne toujours d'un coût/risque, n'est-ce pas ?
Si vous pensez, Chester, revenons au processeur 6502 qui était célèbre dans l'Apple II, le VIC-20, le Commodore 64… si vous êtes du Royaume-Uni, c'était dans le BBC Micro.
Je crois que cette puce avait environ 4000 transistors.
C'était donc vraiment une puce à jeu d'instructions réduit, ou RISC.
Alors que je comprends que le dernier processeur Apple M2 a 20 milliards (comme dans 20,000,000,000 XNUMX XNUMX XNUMX) de transistors, juste dans un seul processeur.
Ainsi, vous pouvez voir que lorsque vous commencez à ajouter des éléments comme le contrôleur d'interruption (qui peut aller dans la puce), l'enclave sécurisée (enfin, qui peut aller dans la puce), l'hyperthreading (qui peut aller dans la puce), [SPEEDING UP MANICALLY] instructions vectorielles (celles-ci pourraient aller dans la puce), exécution spéculative, réorganisation des instructions, multicœurs…
…tout cela, il n'est pas surprenant que parfois les choses ne fonctionnent pas comme on pourrait s'y attendre, et qu'il faille beaucoup de temps pour que quiconque s'en aperçoive.
CHET. Eh bien, bon travail aux chercheurs qui l'ont trouvé, car c'est certainement une recherche intéressante.
Et si vous souhaitez en comprendre un peu plus, votre article Naked Security l'explique incroyablement bien pour les personnes qui ne connaissent normalement pas des choses comme les contrôleurs APIC.
Je recommande donc aux gens de le vérifier, car c'est un exemple parfait des conséquences imprévues de décisions simples prises sur des choses très complexes.
CANARD. Je pense que c'est une excellente façon de le dire. Chester.
Cela nous laisse également la liberté de passer à une autre question controversée, à savoir le fait que le gouvernement américain est offrant une récompense qu'il dit est "jusqu'à 10 millions de dollars" pour des informations sur l'équipe du rançongiciel Conti.
Maintenant, il semble qu’ils ne connaissent le vrai nom de personne.
Ces personnes ne sont connues que sous les noms de Dandis, Professeur, Reshaev, Target et Tramp.
Et leurs photos ne sont que des silhouettes…
CHET. Oui, quand j'ai vu l'article pour la première fois, j'ai pensé que la description des criminels ressemblait aux gens de Gilligan's Island.
Nous avons le professeur et le clochard… et je ne savais pas trop où cela voulait en venir avec les surnoms.
J'espère que cette tentative aura plus de succès que la précédente… Je veux dire, il y avait un autre groupe pour lequel ils ont offert 10 millions de dollars, qui était le groupe Evil Corp.
Et à ma connaissance, aucune arrestation ni aucune action en justice n'a encore été entreprise. Donc, vraisemblablement, les 10 millions de dollars pour obtenir Evil Corp n'étaient pas suffisants pour inciter les gens à se retourner contre les auteurs de ce groupe.
Alors, j'espère que celui-ci aura un peu plus de succès.
Mais il y avait une photo fantastique qui a suscité beaucoup de spéculations et de conversations sur les Twitter et même sur Naked Security, dans le message que tu as écrit, de l’un des auteurs présumés.
Nous ne savons pas s'il est membre du groupe de contrôle qui a exécuté ou exploité le Ransomware-as-a-Service, ou s'il était simplement peut-être un affilié qui a utilisé le malware et a contribué au paiement de commissions sur les gains mal acquis de victimes.
Mais vous ne pourriez pas être plus stéréotypé russe… Je veux dire, nous regardons ça : le gars a une étoile rouge sur sa casquette, et je suppose qu'il a une petite bouteille de vodka à la main, et il y a une balalaïka.
C'est presque trop beau pour être vrai.
CANARD. Et, en bonne tenue de hacker, il porte une sorte de doudoune avec un sweat à capuche sur…
… bien qu'il ait baissé le sweat à capuche, alors peut-être que ça ne compte pas ?
Pensez-vous, Chester, qu'ils ont ciblé le gang Conti parce qu'ils avaient un peu de déshonneur parmi les voleurs, pour ainsi dire ?
Il y a environ un an, certains des affiliés se sont énervés, ont affirmé qu'ils se faisaient arnaquer, et il y a eu une violation de données, n'est-ce pas, où l'un d'eux a jeté tout un tas de manuels d'utilisation et de fichiers logiciels ?
CHET. Vous savez, il y a beaucoup de pièces là-bas.
Comme vous le soulignez – je crois que c'était en août 2021 – quelqu'un divulgué leurs manuels d'utilisation, ou leur « playbook », comme on l'appelle.
Après l’invasion de l’Ukraine, Conti en tant qu’entité semblait très pro-russe, ce qui a poussé un groupe d’Ukrainiens qui faisaient partie de leur projet à se retourner contre eux et à divulguer un tas d’informations sur leurs opérations et autres.
Donc, il y a certainement eu des choses là-bas.
Je pense qu'une autre raison, Duck, est simplement le énorme quantité de dégâts ils ont causé.
Je veux dire, lorsque nous avons fait nos comptes rendus de notre équipe d'intervention rapide, sans aucun doute le groupe le plus prolifique en 2021 causant des dommages était Conti.
Personne ne croit vraiment qu'ils sont sortis de la clandestinité criminelle.
Ce n'est pas comme s'ils avaient pris leur argent et s'en étaient allés… ils ont simplement évolué vers de nouveaux stratagèmes et se sont divisés en différents groupes de rançongiciels, et jouent des rôles différents dans la communauté qu'ils ne l'étaient.
Et plus récemment, certaines personnes ont peut-être entendu dire qu'il y avait eu des attaques contre le gouvernement du Costa Rica qui avaient été attribuées à Conti, et ce n'était même pas il y a très longtemps.
Je pense donc qu’il y a des couches ici, et l’une de ces couches pourrait être celle de Dandis, du professeur, de Reshaev…
… ces personnes ont été quelque peu doxxées publiquement [si des données personnelles ont été divulguées délibérément] par des personnes qui prétendent savoir qui elles sont, mais sans fournir de preuves qui mériteraient des inculpations et des condamnations.
Et donc c'est peut-être un espoir qu'ils vont peut-être avancer si le prix est assez élevé et se retourner contre leurs anciens camarades.
CANARD. Cependant, même s'ils sont tous arrêtés demain, et qu'ils sont tous inculpés, et qu'ils sont tous condamnés, cela ferait une brèche dans les procédures contre les ransomwares, n'est-ce pas ?
Mais malheureusement, ce serait une *denture*, pas *la fin de*.
CHET. Absolument.
Malheureusement, c'est le monde dans lequel nous vivons ces jours-ci.
Je pense que nous continuerons à voir ces crimes évoluer de différentes manières, et nous espérons que cela apportera un certain soulagement à mesure que nous nous améliorerons de plus en plus dans notre défense.
Mais avec des rançons potentielles de 25 millions de dollars, de nombreuses personnes sont prêtes à tenter leur chance et à continuer de perpétrer ces crimes, que ces seigneurs du crime en particulier soient aux commandes ou non.
CANARD. Oui.
Vous pensez : « Oh, eh bien, ils n'obtiendront jamais 25 millions de dollars. Ils se contenteraient probablement de moins à la fin.
Mais même si ce chiffre se résume à, disons, 250,000 XNUMX $...
… comme le souligne l'équipe US Rewards for Justice : depuis 2019, ils affirment que le seul gang Conti (citant le site RfJ), que leur ransomware a été utilisé pour mener plus de 1000 attaques de ransomware ciblant des infrastructures critiques américaines et internationales.
Services médicaux, centres de répartition 9-1-1, villes, municipalités.
Et ils suggèrent que rien que pour les réseaux de soins de santé et de premiers intervenants – des choses comme les ambulanciers, les pompiers, les hôpitaux – plus de 400 dans le monde ont été touchés, dont 290 aux États-Unis.
Donc, si vous multipliez 290 par (j'utilise des citations aériennes géantes ici) par les "frais d'actualisation" de 250,000 XNUMX $ qui auraient dû être consacrés à la prestation de soins de santé…
… vous obtenez un nombre extrêmement élevé de toute façon.
CHET. Rappelez-vous, il y a quatre ans, lorsque nous avons publié un reportage sur SamSam et nous avons été étonnés qu'ils aient gagné 6 millions de dollars sur trois ans ?
CANARD. C'est quand même beaucoup d'argent, Chester !
Eh bien, c'est pour moi… peut-être que vous êtes un haut vol. [RIRE]
Je sais que vous avez un sujet – nous n'avons pas écrit cela sur Naked Security, mais c'est quelque chose qui vous intéresse beaucoup…
…et c'est le fait qu'il ne peut y avoir « un seul cercle pour tous les gouverner » en matière de cybersécurité.
En particulier lorsqu'il s'agit de choses comme les soins de santé et les premiers intervenants, où tout ce qui pourrait gêner l'amélioration de la sécurité pourrait en fait aggraver dangereusement le service.
Et vous avez une histoire des National Institutes of Health à raconter…
CHET. Oui, je pense que c'est un rappel important que nous sommes d'abord et avant tout responsables de la gestion des risques, et non des résultats qui aboutissent à une sécurité parfaite.
Et je pense que beaucoup de pratiquants l'oublient trop souvent.
Je vois beaucoup de ces arguments, notamment sur les réseaux sociaux : « le parfait est l'ennemi du bien », dont nous avons également parlé précédemment dans les podcasts…
… où, "Vous devriez le faire de cette façon, et c'est la seule bonne façon de le faire."
Et je pense que c'est intéressant - ce étude de la relation entre les hôpitaux qui ont subi une violation de données et les résultats des patients à la suite de ces violations de données.
Cela n'a peut-être pas de sens à première vue, mais permettez-moi de vous lire les principales conclusions, qui, je pense, montrent très clairement de quoi nous parlons.
Les principales conclusions sont les suivantes :
Le temps nécessaire à l'hôpital pour réaliser un électrocardiogramme a augmenté jusqu'à 2.7 minutes, et la mortalité par infarctus aigu du myocarde à 30 jours a augmenté jusqu'à 0.36 point de pourcentage au cours des trois années suivant une violation de données.
Essentiellement, ce que nous disons, c'est qu'un tiers de pour cent de plus de personnes sont décédées de crises cardiaques dans les hôpitaux qui ont subi des violations de données par la suite qu'avant, en pourcentage de patients qui ont eu une issue fatale.
CANARD. Vraisemblablement, l'implication est que s'ils avaient pu obtenir cet électrocardiogramme sur eux et obtenir les résultats et prendre une décision clinique plus rapidement, ils auraient peut-être pu sauver un nombre non négligeable de personnes décédées ?
CHET. Oui, et je pense que lorsque vous pensez à un hôpital très fréquenté, où les gens viennent régulièrement avec des crises cardiaques et des accidents vasculaires cérébraux, 1 patient sur 300 mourant à cause de nouveaux protocoles de sécurité est une sorte de préoccupation.
Et la Health and Human Services Administration des États-Unis poursuit en recommandant que les hôpitaux concernés « évaluent soigneusement les initiatives de sécurité correctives pour obtenir une meilleure sécurité des données sans affecter négativement les résultats des patients ».
Et je pense que c'est vraiment là que nous devons être super prudents, non ?
Nous voulons tous une meilleure sécurité des informations, et je veux que mes dossiers de patients soient conservés en lieu sûr lorsque je me rends à l'hôpital.
Et nous voulons certainement être sûrs que les gens n'accèdent pas aux ordinateurs et aux dossiers qu'ils ne devraient pas, et que les gens ne dispensent pas de médicaments qu'ils ne devraient pas et qui peuvent être nocifs.
D'un autre côté, c'est la vie ou la mort.
Et bien que cela puisse ne pas s'appliquer à votre cabinet d'avocats, à votre société de marketing ou à votre usine dont vous êtes responsable de la sécurité… Je pense que c'est un rappel important qu'il n'y a pas de solution unique pour la sécurité.
Nous devons évaluer chaque situation et nous assurer que nous l'adaptons au niveau de risque que nous sommes prêts à accepter.
Et personnellement, je suis prêt à accepter beaucoup plus de risque que mon dossier médical soit compromis que de risque de mourir parce que quelqu'un a dû aller chercher un code à deux facteurs pour déverrouiller l'électrocardiogramme !
CANARD. Eh bien, Chester, vous êtes diabétique de type 1, n'est-ce pas ?
Et vous avez une de ces pompes à insuline magiques.
Maintenant, je parie que vous ne vous précipitez pas pour installer le dernier noyau Linux dès qu'il sort !
CHET. Absolument!
Je veux dire, ces appareils sont soumis à des tests rigoureux… cela ne veut pas dire qu'ils sont exempts de bogues, mais le connu vaut mieux que l'inconnu quand vous parlez de votre santé et que vous êtes capable de la gérer.
Et il y a certainement des bugs logiciels dans ces appareils, et ils se modernisent et incluent des technologies comme Bluetooth… ou le grand pas en avant pour mon appareil, c'est qu'il a un écran couleur, qui vous indique l'âge de certaines technologies utilisées dans ces appareils. les choses sont!
Les autorités médicales pour approuver ces dispositifs ont un processus très, très long.
Et les choses « éprouvées » (comme dans la conversation précédente sur les transistors et les processeurs), les choses simples que nous pouvons comprendre, sont de loin préférées aux choses nouvelles et compliquées qui sont beaucoup plus difficiles à comprendre et à trouver ces failles de sécurité.
Je ne peux pas imaginer, s'il y avait une telle chose comme un Patch Tuesday pour cette pompe à insuline, que je ferais la queue pour être le premier gars sur le bloc mardi pour installer la mise à jour !
Malgré toutes ses verrues, je sais exactement comment ça marche et comment ça ne marche pas.
Et à votre avis, je cohabite bien avec ça…
…l'appareil connaît sa responsabilité de rester cohérent, et j'ai appris à l'exploiter à mon avantage pour améliorer ma santé.
Tout changement à cet égard peut être effrayant et perturbateur.
Ainsi, la réponse n'est pas toujours meilleure, plus rapide et plus intelligente.
Parfois, ce sont les « connus connus » dans la fiabilité et la confiance.
CANARD. Cela dit, ne pas avoir de violations de données aide également !
Et il y a des choses étonnamment simples que vous pouvez faire pour protéger votre organisation des données qui sortent là où elles ne devraient pas.
CHET. Et l'une des choses, Duck, c'est qu'on n'a plus le temps qu'on avait avant.
Les criminels parcourent perpétuellement Internet à la recherche de l'une de ces erreurs que vous avez pu commettre, qu'il s'agisse d'une politique obsolète autorisant trop de choses, ou s'il s'agit de services exposés qu'il était peut-être parfaitement acceptable d'exposer il y a dix ans, mais qu'il est maintenant dangereux d'avoir exposés à Internet.
CANARD. "Le RDP que le temps a oublié."
CHET. Oui, eh bien, je suis triste de penser que RDP revient sans cesse, mais en fait, chez Black Hat la semaine dernière, nous venons de publier un article et a écrit un blog à propos d'une situation où une organisation a eu trois attaques de ransomware différentes en quelques semaines, toutes au sein de la même organisation, se produisant quelque peu simultanément.
Et ce n'est pas la première fois que nous voyons plus d'un attaquant à l'intérieur d'un réseau.
Je pense que c'est peut-être la première fois que nous en voyons *trois* dans le même réseau.
CANARD. Oh, bon sang, se sont-ils chevauchés ?
Étaient-ils littéralement toujours confrontés à l'attaque A lorsque l'attaque B est arrivée ?
CHET. Oui, je crois qu'il y avait un écart entre l'attaquant B et l'attaquant C, mais A et B étaient en même temps, vraisemblablement via la même faille de l'outil d'accès à distance qu'ils avaient tous deux trouvée et exploitée.
Et puis, je crois, le groupe B a installé son propre outil d'accès à distance, une sorte de porte dérobée secondaire juste au cas où la première serait fermée…
… et le groupe C a trouvé son outil d'accès à distance et est entré.
CANARD. Bon sang… il ne faut pas rire, mais c'est une sorte de comédie d'erreurs.
Il est facile de dire : "Eh bien, dans tout réseau à moitié bien géré, vous devriez savoir quel est votre outil d'accès à distance officiel, de sorte que tout ce qui n'est pas celui-là devrait se démarquer évidemment."
Mais permettez-moi de demander ceci à nos auditeurs : si vous êtes en charge d'un réseau, pouvez-vous mettre la main sur votre cœur et me dire exactement combien d'outils de téléconférence vous utilisez actuellement dans votre entreprise ?
CHET. Oui, absolument.
Nous avons eu une victime que nous avons écrite plus tôt cette année qui, je crois, avait * huit * outils d'accès à distance différents que nous avons trouvés au cours de notre enquête, dont certains étaient légitimement utilisés il y a dix ans, et ils ont simplement cessé de les utiliser mais ne les ont jamais supprimés.
Et d'autres qui avaient été introduits par plusieurs acteurs de la menace.
C'est donc certainement quelque chose à surveiller!
CANARD. Eh bien, Chester, espérons que c'est une suggestion assez optimiste sur laquelle terminer, car nous n'avons plus de temps pour cette semaine.
Merci beaucoup, comme toujours, d'avoir pris le micro dans un délai très court.
Et, comme toujours, il me reste simplement à dire : A la prochaine…
TOUS LES DEUX. Restez en sécurité!
[MODÈME MUSICAL]
- AEPIQUE
- blockchain
- cognitif
- Conti
- portefeuilles de crypto-monnaie
- cryptoexchange
- de la cryptographie
- la cyber-sécurité
- les cybercriminels
- Cybersécurité
- département de la Sécurité intérieure
- portefeuilles numériques
- pare-feu
- la médecine
- Intel
- Kaspersky
- La loi et l'ordre
- malware
- Mcafee
- Sécurité nue
- Podcast de sécurité nu
- NexBLOC
- Platon
- platon ai
- Intelligence des données Platon
- Jeu de Platon
- PlatonDonnées
- jeu de platogamie
- Podcast
- la confidentialité
- ransomware
- VPN
- la sécurité d'un site web
- zéphyrnet
- zoom
