Je trouve l'article intéressant, surtout pour les personnes comme moi qui n'ont que peu de connaissances en systèmes et réseaux.
Les solutions déployées sont probablement réservées à des clients grands comptes. Même si le risque d'attaque est moindre, il me semble que les PME sont exposées à une double problématique de connaissance et de coût.
Est-ce que des solutions abordables existent pour des PME ? Quels interlocuteurs peuvent les accompagner dans une démarche de sécurisation ?
Et c'est un vrai problème dans certains domaines critiques (aéronautique, nucléaire, etc…).
J'ai toujours trouvé complètement dingue d'utiliser des logiciels propriétaires étrangers (en l'occurrence des GAFAM) pour gérer des données parfois vitales pour l'entreprise. J'ai vu des employés Airbus échanger des secrets industriels via Gmail, j'ai vu des serveurs Windows hébergeant des contrats confidentiels chez Sun Aero etc…
Ca rend fou. D'autant plus que quand tu mentionnes les risques, on te rit au nez 90% du temps et on te dit que tu exagères. Par contre ça vient pleurer quand la concurrence américaine vient prendre le marché grâce aux secrets industriels acquis…
Tant que l'industrie française n'aura pas pleinement conscience de ça, faudra pas s'étonner que tous les marchés nous passent sous le nez à chaque fois.
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
Les clouds sont en général plus sécurisé que votre réseau
Oui, l'infra du Cloud est protégée (et avec plein de certifs de haut niveau), mais il est parfaitement possible d'implémenter une passoire sur un cloud public, ça arrive tous le temps.
Mais chez eux, les mises à jour c’est toutes les semaines ! Comment veulent-ils que nous mettions à jour huit cents serveurs toutes les semaines !? L’effort à produire est colossal, c’est complètement incohérent ! »
Entendre ça en 1995 ou 2000, peut-être.
En 2021 non.
La question c'est pas la vitesse des updates, c'est l'analyse de l'impact des failles, l'application d'éventuelles mesures de contournements quand elles existe et le patching des plus critique immédiates, des autres de manière régulière (même si pas toutes les semaines).
La question c'est pas la vitesse des updates, c'est l'analyse de l'impact des failles, l'application d'éventuelles mesures de contournements quand elles existe et le patching des plus critique immédiates, des autres de manière régulière (même si pas toutes les semaines).
Et beaucoup de test pour valider rapidement l'impact des mises à jour.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
La question c'est pas la vitesse des updates, c'est l'analyse de l'impact des failles
Et dans l'article il est dit qu'il s'est fait avoir initialement par un phishing. Du coup, la vitesse d'update n'a rien à voir.
Ensuite, ils ont utilisé une faille de sécurité. Mais c'est pas sur. Quand tu vois la facilité avec laquelle un pentester devient admin de domaine, ça fait peur. Et souvent c'est parce que les mots de passe admin traînent sur le réseau. Du coup l'attaquant n'utilise aucune faille de sécurité.
Donc tu peux être 100% à jour et de prendre un ransomware.
Avec 800 serveurs, bonne chance pour tout gérer dans un keepass. Non pas que c'est infaisable, mais 800 serveurs ça veut dire un paquet d'équipes, encore plus d'utilisateurs, vraisemblablement des développeurs et autant de chances de voir un password.xls, un script powershell avec le pass en clair pour monter un lecteur réseau, ou un admin qui s'est loggé il y a 1000 ans sur une machine et que mimikatz saura extraire.
il y a des outils qui permettent de partager des mots de passe sans avoir à les extraires de façon permanente et déchiffrée sur un fichier.
Certe tu peux sûrement en voler quelques uns ça et là dans le buffer dur copier/coller mais pas tout en entier et si tu as des mots de passe différents partout la compromission d'un serveur a moins de chance de se propager.
Mais bon tout ça peut péter quand même avec des comptes admins de domaines qu'il est fréquent de voir utilisé partout et pour n'importe quoi, y compris sur se logger sur des serveurs alors que ça ne devrait être utilisé…que pour administrer le domaine lui-même.
Une bonne segmentation réseau, des transferts de données via des API et queues et pas des partages réseau, diminueraient d'autant plus le rayon d'impact.
Je trouve que ce récit décrit un peu trop les choix d'outil et pas assez les processus, archi, etc.
Windows, Linux, MS SQL Server ou Postgres, Veeam ou rubrik, c'est pas tellement les choix d'outils qui ont posé problème d'après ce que je vois mais plus les processus (peu de maj, pas d'analyse sécu des failles), du staffing[1], le manque d'isolation des infras entre elles, probablement de l'architecture des applis et flux (j'ai vu passer des histoires de partages réseaux, ça sent le bordel à l'ancienne…).
[1] chaque boite a un responsable de sécu qui va écrire les grandes lignes et proposer, là-encore, des outils Mais peu nombreuses sont celles qui ont des ingénieurs dédiés à la sécurité dans chaque équipes (réseau, infrastructure developpement).
D'une manière générale, l'arrivée "d'Internet tout le temps" est sous-estimée en terme de problèmes potentiels.
Dans une entreprise qui a commencé avec un catalogue de vente par correspondance et qui est passé d'abord à l'informatisation du SI puis à la vente en ligne, on a vite fait d'avoir des p'tits trous. Et oui, tant qu'une cata n'est pas arrivé, on croit être en sécurité.
Le manque de moyens humains est compensé par des architectures simples, à plat ou presque. Qui sont ingérables car les flux ne sont pas maîtrisés.
Ça donne en effet l'impression d'un truc qui s'est construit petit bout par petit bout au fil du temps. À un moment ça finit par branler de partout. Et ça explique sans doute la remarque sur le problème des mises à jour.
Cela dit, dans l'histoire, ce que je relève aussi la confiance initiale en Microsoft pour un résultat disons mitigé : "payez d'ailleurs et on verra ça quand on aura un peu de temps".
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
# Intéressant
Posté par dark_moule . Évalué à 1.
Je trouve l'article intéressant, surtout pour les personnes comme moi qui n'ont que peu de connaissances en systèmes et réseaux.
Les solutions déployées sont probablement réservées à des clients grands comptes. Même si le risque d'attaque est moindre, il me semble que les PME sont exposées à une double problématique de connaissance et de coût.
Est-ce que des solutions abordables existent pour des PME ? Quels interlocuteurs peuvent les accompagner dans une démarche de sécurisation ?
[^] # Re: Intéressant
Posté par Pol' uX (site web personnel) . Évalué à 4.
Beh ça semble très atteignable pour une PME de ne pas avoir de windows server, non ?
Adhérer à l'April, ça vous tente ?
[^] # Re: Intéressant
Posté par claudex . Évalué à 4.
Je dirais que ça dépend du domaine, il y a pas mal de logiciels métiers qui ne tournent que sous Windows.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Intéressant
Posté par Nibel . Évalué à 10.
Et c'est un vrai problème dans certains domaines critiques (aéronautique, nucléaire, etc…).
J'ai toujours trouvé complètement dingue d'utiliser des logiciels propriétaires étrangers (en l'occurrence des GAFAM) pour gérer des données parfois vitales pour l'entreprise. J'ai vu des employés Airbus échanger des secrets industriels via Gmail, j'ai vu des serveurs Windows hébergeant des contrats confidentiels chez Sun Aero etc…
Ca rend fou. D'autant plus que quand tu mentionnes les risques, on te rit au nez 90% du temps et on te dit que tu exagères. Par contre ça vient pleurer quand la concurrence américaine vient prendre le marché grâce aux secrets industriels acquis…
Tant que l'industrie française n'aura pas pleinement conscience de ça, faudra pas s'étonner que tous les marchés nous passent sous le nez à chaque fois.
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
[^] # Re: Intéressant
Posté par cg . Évalué à 5.
Il y a des ransomwares qui fonctionnent sur Linux. Il y en a moins, mais la logique voudrait qu'il y en ait de plus en plus.
[^] # Re: Intéressant
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
Il faut absolument tout mettre à jour. Il ne faut pas croire que l'interieur du reseau est safe : il prévoir de l'authentification sur chaque service.
Les clouds sont en general plus securisé que votre reseau. Les sauvegardes sont à faire.
"La première sécurité est la liberté"
[^] # Re: Intéressant
Posté par cg . Évalué à 5.
Oui, l'infra du Cloud est protégée (et avec plein de certifs de haut niveau), mais il est parfaitement possible d'implémenter une passoire sur un cloud public, ça arrive tous le temps.
# Il y a quand même de la grande naïveté
Posté par Psychofox (Mastodon) . Évalué à 7.
Entendre ça en 1995 ou 2000, peut-être.
En 2021 non.
La question c'est pas la vitesse des updates, c'est l'analyse de l'impact des failles, l'application d'éventuelles mesures de contournements quand elles existe et le patching des plus critique immédiates, des autres de manière régulière (même si pas toutes les semaines).
[^] # Re: Il y a quand même de la grande naïveté
Posté par claudex . Évalué à 6.
Et beaucoup de test pour valider rapidement l'impact des mises à jour.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Il y a quand même de la grande naïveté
Posté par octane . Évalué à 7.
Et dans l'article il est dit qu'il s'est fait avoir initialement par un phishing. Du coup, la vitesse d'update n'a rien à voir.
Ensuite, ils ont utilisé une faille de sécurité. Mais c'est pas sur. Quand tu vois la facilité avec laquelle un pentester devient admin de domaine, ça fait peur. Et souvent c'est parce que les mots de passe admin traînent sur le réseau. Du coup l'attaquant n'utilise aucune faille de sécurité.
Donc tu peux être 100% à jour et de prendre un ransomware.
[^] # Re: Il y a quand même de la grande naïveté
Posté par ChocolatineFlying . Évalué à 1.
si tu es 100 % à jour en général ton mdp ne traine pas sur le réseau et tu utilise keepass pour le gérer :)
[^] # Re: Il y a quand même de la grande naïveté
Posté par octane . Évalué à 2.
Avec 800 serveurs, bonne chance pour tout gérer dans un keepass. Non pas que c'est infaisable, mais 800 serveurs ça veut dire un paquet d'équipes, encore plus d'utilisateurs, vraisemblablement des développeurs et autant de chances de voir un password.xls, un script powershell avec le pass en clair pour monter un lecteur réseau, ou un admin qui s'est loggé il y a 1000 ans sur une machine et que mimikatz saura extraire.
[^] # Re: Il y a quand même de la grande naïveté
Posté par Psychofox (Mastodon) . Évalué à 5.
il y a des outils qui permettent de partager des mots de passe sans avoir à les extraires de façon permanente et déchiffrée sur un fichier.
Certe tu peux sûrement en voler quelques uns ça et là dans le buffer dur copier/coller mais pas tout en entier et si tu as des mots de passe différents partout la compromission d'un serveur a moins de chance de se propager.
Mais bon tout ça peut péter quand même avec des comptes admins de domaines qu'il est fréquent de voir utilisé partout et pour n'importe quoi, y compris sur se logger sur des serveurs alors que ça ne devrait être utilisé…que pour administrer le domaine lui-même.
Une bonne segmentation réseau, des transferts de données via des API et queues et pas des partages réseau, diminueraient d'autant plus le rayon d'impact.
# récit et conclusions
Posté par Psychofox (Mastodon) . Évalué à 10.
Je trouve que ce récit décrit un peu trop les choix d'outil et pas assez les processus, archi, etc.
Windows, Linux, MS SQL Server ou Postgres, Veeam ou rubrik, c'est pas tellement les choix d'outils qui ont posé problème d'après ce que je vois mais plus les processus (peu de maj, pas d'analyse sécu des failles), du staffing[1], le manque d'isolation des infras entre elles, probablement de l'architecture des applis et flux (j'ai vu passer des histoires de partages réseaux, ça sent le bordel à l'ancienne…).
[1] chaque boite a un responsable de sécu qui va écrire les grandes lignes et proposer, là-encore, des outils Mais peu nombreuses sont celles qui ont des ingénieurs dédiés à la sécurité dans chaque équipes (réseau, infrastructure developpement).
[^] # Re: récit et conclusions
Posté par cg . Évalué à 5.
D'une manière générale, l'arrivée "d'Internet tout le temps" est sous-estimée en terme de problèmes potentiels.
Dans une entreprise qui a commencé avec un catalogue de vente par correspondance et qui est passé d'abord à l'informatisation du SI puis à la vente en ligne, on a vite fait d'avoir des p'tits trous. Et oui, tant qu'une cata n'est pas arrivé, on croit être en sécurité.
Le manque de moyens humains est compensé par des architectures simples, à plat ou presque. Qui sont ingérables car les flux ne sont pas maîtrisés.
[^] # Re: récit et conclusions
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 8.
Ça donne en effet l'impression d'un truc qui s'est construit petit bout par petit bout au fil du temps. À un moment ça finit par branler de partout. Et ça explique sans doute la remarque sur le problème des mises à jour.
Cela dit, dans l'histoire, ce que je relève aussi la confiance initiale en Microsoft pour un résultat disons mitigé : "payez d'ailleurs et on verra ça quand on aura un peu de temps".
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.