pasBill pasGates a écrit 16038 commentaires

LOL

Mon dieu, tu n'as jamais vu de l'administration de parc Windows toi

L'administration graphique c'est une toute petite partie. Le plus important est ailleurs : gestion des certificats des machines, de DNS, des policies, etc… et sous Windows tu peux faire tout cela en Powershell, et le faire en remote afin que tout soit automatisé, documenté, … C'est ainsi que plein d'entreprises font cela.

Alors oui la petite PME de 10 employés ou l'admin est plombier, ils utilisent l'UI, mais quand t'as un département informatique et un parc large, tes administrateurs font énormement en powershell et de temps en temps autres langages.

Non.

Parce que des le moment où le patch est public c'est la course contre la montre pour patcher avant que le crime organisé et autre fans de malware fassent du reverse engineering sur le patch, trouvent la faille et l'exploitent.

"notre" ? Tu étais dans quelle équipe? Ca devait être cool comme job (0 ironie ici).

J'étais le manager du team d'ingénieurs dans MSRC qui traite tous les rapports externes de vulnerabilités. Une dizaine d'ingénieurs sécurité dont le boulot est d'évaluer les rapports, à quel point le problème est exploitable, s'assurer que les patchs corrigent le problème correctement, trouver les variantes, … On a eu Flame, Duqu, etc… en avant première, c'était fun et assez unique.

je vais me faire l'avocat du diable, mais pousser des correctifs le 2e mardi du mois, c'est quelque fois pénible aussi. "ooops le bug, là, il est pas complètement patché, va falloir attendre le mois prochain, allez salut"

Cela dépend, si une variante passe dans les mailles, ou si le bug originel est pour je ne sais quelle raison par corrigé proprement, selon les cas MS va sortir un patch en urgence et ne pas attendre le mois prochain.

De nouveau, cette cadence du 2eme mardi du mois ne vient pas de MS mais de demandes d'entreprises car cela simplifie leurs tests. On faisait les patchs sans cadence avant, c'est à la suite de demandes d'entreprises que l'on a changé.

Parceque typiquement, aujourd'hui qu'est ce qui te permet de dire qu'un bug va être exploitable ou pas?

Quand j'étais à Microsoft, c'était notre boulot journalier: évaluer la dangerosité des bugs qui nous sont rapportés. Cela demande une expertise particulière en exploitation, mais c'est tout à fait faisable, la preuve étant que plein de gens font cela à longueur de journée dans leur boulot.

Et oui, ce n'est pas une science exacte, et il y a toujours la question de "on va être conservateur, et marquer des bugs exploitables si on est pas sûr" ou "c'est peu probable, marquons le non-exploitable" , mais cela a une valeur significative pour les utilisateurs (entreprises principalement). Il faut bien comprendre qu'à Microsoft on avait pas décidé de nous même de faire tout cela, ce sont les clients qui le demandaient, histoire de pouvoir mettre une priorité sur leur travail de test et deployment, parce que ces étapes ont un coût clair pour eux.
De même que rester exposés à des failles car ils ne sont même pas au courant qu'une faille existait et qu'ils n'ont dés lors pas patché, c'est un vrai gros problème pour eux.

Il est pas constructif, et ne me semble pas compétent vu son approche qui lui fait affirmer des choses clairement dans fondement, si je perd ces gens là cela me va.

Oh mais perso si il ne veut pas de laptop d'entreprise à la maison cela ne me gène pas. C'est son choix. Personne ne l'oblige à se connecter depuis chez lui, il est libre de choisir de prendre son velo ou sa voiture pour venir au boulot chaque fois qu'il a besoin de faire quelque chose.

Le laptop d'entreprise à la maison en ce qui me concerne c'est une option que l'employé a, pas une obligation, pour faire son boulot.

Mais mon cher, tu mélanges tout.

Oui les name drop et autres tentatives de faire grossir les effets d'un bug sont pathetique, mais cela ne change rien au fait qu'un bug de securité, c'est à dire un bug qui est exploitable hein sinon c'est pas un problème de sécurité, est quelque chose qui doit être clairement marqué, histoire que les gens puissent évaluer si cela les concerne, si ils doivent patcher vite, etc…

C'est justement à cela que ces CVEs et ces scores CVSS servent, et non, les défenses du kernel, elles ne font pas tout, pour une attaque en local notamment (ex: KASLR ne sert à rien), et "local", avec les containers, le serverless, etc… et toutes ces boites qui font du multi-tenant sur une même machine cela concerne beaucoup de machines de nos jours.

Justement non

Un bug sécurité n'est pas juste un bug, et ne pas clarifier que ces bugs ont un impact sécurité est un énorme problème.

Un bug qui t'empêche disons de connecter une caméra USB moi je ne peux rien en faire pour détruire ta vie ou tes finances.

Un bug qui me donne accès a distance a ta machine par contre, cela me permet de choper tout ce que tu fais sur ta machine : tes photos en string léopard, les mots de passe de ta banque, tes clefs Bitcoin, etc..

Un bug sécurité est très différent et c'est bien pour cela que le monde de la sécurité trouve l'approche des gens du noyau complètement stupide.

Je vais me contenter de laisser cela ici, c'est tout frais :

https://twitter.com/chompie1337/status/1606334674338447360

Ton commentaire est propriétaire ? Parce que c'est en effet un bel exemple de fud.

La meilleure aide à lui donner n'est pas les détails techniques du cas présent mais lui faire comprendre que lancer des affirmations sans aucun élément concret qu'il puisse articuler va être problématique pour la suite de sa carrière.

Et c'est l'élément principal de ma prose : il balance des affirmations en l'air. Que ce soit sur Windows ou sur le fonctionnement d'une voiture n'est au final pas très important.

Tout a fait.

Mais avoir des doutes c'est "j'ai entendu des rumeurs sur X, je voudrais des éclaircissements"

et pas

"X est rempli de mouchards, je veux autre chose et je ne veux pas de cet EDR qui lui aussi est dangereux" quand il n'a absolument aucun élément concret derrière ces mots.

Le problème dans sa prose est qu',il affirme plutôt que questionner.

Ses raisons ne tiennent pas debout justement. Je n'ai jusqu'à maintenant vu aucune critique qui a une once de réalisme, juste du FUD basé sur de l'ignorance et ses idées préconçues.

Que l'entreprise lui décrive ce qu'est le laptop, les apps installées, etc… tout a fait, c'est essentiel.

Mais aller nourrir ses idées préconçues en lui permettant d'enlever un outil essentiel à la sécurité du réseau d'entreprise non. Le jour où il viendra avec un problème concret on en reparle, d'ici-là il devrait penser à s'attacher aux faits, pas à ses idées préconçues qu'il est incapable d'arguments proprement.

Je souligne le dernier point parce que j'imagine qu'il est informaticien, pas vendeur de carottes, c'est son job de faire des choix techniques argumentés et savoir dire "je ne sais pas" ou "je ne suis pas sur" quand la situation le demande.

Aucune aggressivité, simplement un constat.

Si un employé vient me dire qu'il refuse d'avoir l'EDR d'entreprise sur sa machine de bureau pour des raisons qui ne tiennent pas debout je lui offre de choisir entre changer d'avis et trouver un autre boulot. Il met mon entreprise en danger avec ses âneries et fait preuve d'un manque de jugement incroyable.

Ces EDR ne vont typiquement pas scanner le réseau, ils se contentent de regarder les connexions locales

Voir le message de flan plus bas.

J'aimerais comprendre, c'est quoi ta peur de l'IA içi ?

Je lis ce qu'il écrit et j'en déduis qu'il ne comprend pas grand chose à la sécurité informatique, et probablement à l'informatique en général.

De cela découle la conclusion qu'il ne maîtrise pas son système.

a) Tu n'as en rien la maitrise de ton système. Tu crois l'avoir, cela s'arrète là

b) Ne pas faire confiance a une machine d'entreprise car elle a Defender APT me fait franchement rigoler. Tu ne comprends visiblement pas grand chose à la sécurité si avoir ce logiciel te fait péter un cable

c) Si j'étais ton bosse je t'enverrais paître avec ta demande d'ordiphone et abonnement. Tu n'as absolument rien comme information te permettant de dire que ce système pose un risque

d) l'idée qu'une entreprise se fait infiltrer car elle a Windows renforce l'image que tu donnes de quelqu'un qui ne comprend rien à la sécurité

En vérifiant les signatures de chaque étape du boot jusqu'à un certain niveau, ce qui permet d'assurer que soit le système a démarré son firmware, bootloader, noyau et drivers essentiels de manière propre soit la machine reporte une erreur.

justement, l'idée meme de linux et des logiciels libres est d'apporter une alternative fiable, fonctionnelle et prete à l'usage (selon les distros) à des utilisateurs finaux n'y connaissant rien.

Toutes les distribs Linux majeures ont des bootloaders signé avec la cléf de Microsoft et s'installent de manière transparente sans avoir à toucher le BIOS.

Les seules personnes qui auraient besoin de toucher le BIOS sont celles qui veulent … bidouiller.

C'est quoi le fil à retordre ?

Aller dans le BIOS, choisir "off" et redémarrer ? Mon cher, si tu n'est pas capable de faire cela alors tu n'as rien d'une bidouilleur.

Secure Boot est utile pour garantir un certain niveau d'integrité du système, ce qui améliore significativement la vie de tous les utiilisateurs, au prix que le 1% de bidouilleurs doit aller taper une coche pour l'enlever au pire.

Et Secure boot n'a rien de propriétaire.

En fait tout ce que tu nous dis c'est que tu n'as absolument jamais mis les pieds dans une boite américaine, que tu ne sais absolument pas de quoi tu parles et que tu as des préjugés gros comme un gratte ciel.

Chez Twitter, comme toutes les autres boites tech US, les DRH n'ont aucun pouvoir de décision sur qui est engagé, ils s'occupent juste de la gestion. Ce sont les ingénieurs qui font les interviews et qui décident de qui passe ou pas.

Perso je pensais partir en voyage d'affaire a Tahiti pendant 14 ans, le temps qu'ils grandissent, mais ma femme a refusé :)

Non là j'ai un gros point de contention au niveau du sommeil…

C'est plutôt aux gens qui répondent "cloud" à l'auteur du journal qu'il faut répondre ça non ?

Non, parce que visiblement lui ne comprend pas que bare metal n'est pas en opposition a cloud

Ça ne change rien au fait que quand les entreprises embauchent des gens certifiés pour un "cloud" ce n'est pas pour le SDK et que les certifications que j'ai vu passer ne portent pas dessus.

Ben faut regarder à qui tu parles. Déjà içi on ne regarde pas les certifs dans les boites ou je suis passé, à l'interview on regarde si tu sais écrire du code, et si tu comprends comment un cloud fonctionne.

Même les formations azure que j'ai aperçu montrent comment cliquer sur vos sites. Pour que ton commentaire soit constructif il aurait fallu nous pointer vers vos certifications d'ingénieurs sdk etc. ;)

Normal, je bosses chez Amazon, aucune chance que les formations Azure en parlent :D

Mais plus sérieusement, c'est parce que tu ne parles visiblement pas aux bonnes personnes. Tu crois que le microservice qui utilise Azure Storage ou S3 il va utiliser des clics pour stocker des données ? Non, le microservice il est écrit en Java, il utilise l'API.
Déployer le microservice ou une update au microservice c'est idem bien évidemment.

Tu postules pour un poste de dev cloud chez les boites US, si tu leur parles de l'interface graphique ils vont te rire au nez et te renvoyer chez toi