Comment gérer la stagnation ?

[baptom76]

Je ne sais pas où trop mettre mon questionnement.
Je suis dans une société depuis 20 ans !!
Depuis 10 ans, je fais beaucoup de réseaux et de sécurités.
Malheureusement, le moindre changement amené la levée de bouclier de la part des autres “informaticiens”. Ex :

• Séparation des réseaux et gestion full DNS → oui, mais tu changes les IP, on ne peut plus travailler. (donc sujet en attente pour étude toujours pas finie (8 ans d’attente))
• Mise en place d’un EDR → à cause de cette “Merde” plus aucun logiciel ne fonctionne. On veut retourner sur un antivirus basique (je reste sur l’EDR mais passe mon temps à prouver le bon fonctionnement).
• Mise en place de la gestion de mot de passe collaboratif → C’est trop compliqué, il faut tout revoir et remettre KeePass.
• Suppression des comptes à privilège → je ne veux pas perdre mes droits, car je veux pouvoir faire ce que je veux.
• Mise en place d’un bastion → Non, ca ne va pas, parce que TeamViewer est mieux !! (c’est vrai que gérer 110 serveurs et 800 Machines avec TeamViewer c’est sécu).
• Mettre du Linux pour les serveurs web → C’est trop compliquer et Linux ne fonctionne pas en entreprise. (Ok alors les pare-feu, depuis quand ça tourne sur du Windows).

Toutes ces batailles m’épuisent, auriez-vous des idées ?? Comment le gérez-vous ?

[Beerfranz]

Au niveau de l’organisation mentale, il faut choisir ses combats ^^
Donc peut être prendre juste un ou 2 sujets à conflits, et arriver jusqu’à ce qu’ils soient clos (accepté et déployé, ou refusé).

Et pour les conflits qui reste, en faire abstraction pour s’y pencher dans plusieurs années, voir jamais.

Pour le projet de changement des réseaux et DNS, si le point de blocage est qu’une équipe n’a pas fait de mises à jour de son côté pour remplacer ses IP par des noms dns, et que tu trouves que c’est plutôt par flemme de leur part, ya truc qui marche bien, c’est de faire un ultimatum, tu fais la bascule même si c’est pas ok pour eux, et ils se démerdent pour rentrer dans le rang. La marche forcée, ça fait du bien des fois, surtout si ça dure depuis 8ans.

[baptom76]

Merci du conseil.
Je prends note.

[nledez]

Hello, c’est le problème de certaines sociétés avec des “vieux” qui ne veulent pas changer.

Je travaillerais sur deux axes :

• Pédagogique. Tu prends des exemples de boites qui se sont fait piraté avec ransomware + grosse difficultés financières. Tu expliques que des chantiers sont là pour limiter la casse avec ce type d’attaque. Tu pointes du doigt les plus grosses failles (Windows, comptes à privilèges, etc). Et pour conclure que tu fais tout ça pour que vous gardiez votre boulot.

• Échanges. Tu trouves ce qui est pénible pour eux dans leurs travaux, puis tu mets en place des outils/méthodes pour leurs simplifiés le travail. Ça compense les trucs qui leur déplaisent.

Maintenant, on en arrive à la réponse que je voulais te faire à chaud en lisant ton message :

Change de boîte. C’est plutôt toxique pour toi. Tu ne vas pas avancer et fatiguer. Si vous subissez une grosse attaque, c’est toi qui seras au charbon pour tout remonter avec que les autres vont attendre tranquillement au café pendant que tu vas tout remonter.

La troisième solution, c’est avec tous ces arguments, allé voir le boss de la boîte lui expliquer tout ça. Et qu’il acte que tous tes chantiers sont prioritaires pour la survie de la boîte.

La sécurité, c’est toujours un investissement qui coute trop cher. Jusqu’au jour où l’on en a besoin. Et à ce moment-là, on se dit que l’on n’en a pas encore fait suffisamment.

P.S. Je suis “vieux”, mais je vis avec mon temps

[baptom76]

Merci !!
Le changement de boite m’appelle de plus en plus.

Pour moi personne n’est vieux tant qu’il ne reste pas dans ses pantoufles !!

[jderrien]

@baptom76

des autres “informaticiens”

Quelques questions ouvertes :

• Qui sont-ils ? Le lien que vous avez n’est pas clair.
• Qui prend les décisions ?
• Les problèmes évoqués sont-ils réels et justifiés ou est-ce que c’est de la mauvaise foi ? (Pour “Linux ne fonctionne pas en entreprise”, on connait déjà la réponse ; pour le changement d’IP, tu peux juste leur dire “IPv6” pour leur mettre la pression, certains risquent de s’évanouir )
• Est-ce que tu peux faire quelque pour que le changement soit moins douloureux ? (parfois dev un petit outil, un wrapper, ou que sais-je peut aider à faire la transition)

Ensuite :

• Soit tu passes par l’aval de ta hiérarchie pour “forcer” le changement, tout en l’accompagnant, car il faut quand même que le service soit rendu et facile d’usage. Le plus difficile étant de déceler la vraie critique de la mauvaise foi, et de pouvoir en ternir compte malgré tout.
• Soit il est temps de passer à autre chose.

Bon courage

[cchaudier]

Je pense qu’il y a un problème de culture partagé.
La qualité ne doit pas être la priorité de tes collègues.

Est-ce que tu diffuse le message du DevOps ? Est-ce que tu partage des articles ou podcast à tes collegues ?
Est-ce que tu as informé tes managers des risques encourus si rien n’est fait ?

Tu fais face à une resistance classique au changement.

@nledez

Change de boîte. C’est plutôt toxique pour toi. Tu ne vas pas avancer et fatiguer. Si vous subissez une grosse attaque, c’est toi qui seras au charbon pour tout remonter avec que les autres vont attendre tranquillement au café pendant que tu vas tout remonter.

Je ne peu que suggérer ça aussi, tu as l’air épuisé de la situation.

Il convient aussi d’expliquer à ton manager pourquoi tu part et quel seront les impactes s’ils ne font rien.

[Uggla]

Pour l’avoir plus ou moins vécu, si tu vois que c’est extrêmement difficile de changer le système ou que cela demande une énergie monstre et que cela t’apporte que pas ou très peu de satisfaction.
Je dirais qu’il faut parfois savoir renoncer et aller voir ailleurs.

La démarche n’est pas forcément évidente et facile, surtout quand tu as passé beaucoup de temps et parfois de bon moment dans une boite.
Cela demande de l’énergie, il faut donc trouver le bon moment pour se lancer. Mais en principe, tu retrouves assez vite une motivation car tu vois de nouvelles personnes, tu fais des entretiens, etc… bref tu apprends et tu rentres dans une phase positive. Tu vas te rendre compte que ce que tu n’arrives pas a mettre en place aujourd’hui, ailleurs au contraire, il y a de la motivation pour avancer sur ces sujets et que justement ton profil est intéressant.

Mais surtout, je crois que quand tu l’as fait une fois, tu débloques mentalement quelque chose. Tu sais que tu pourras le refaire si nécessaire. En conséquence tu gagnes une certaine “liberté”, en te sentant moins “bloqué” si la situation devait se reproduire ou si elle ne te convenait pas.

[baptom76]

Merci Christophe,
Désolé pour la réponse tardive (petit tour au FIC)
Oui, je diffuse des messages ainsi que votre (toi et les contributeurs) excellent podcast.
Les podcasts de Zavki, NolimitSecu … ainsi que les attaques potentielles qui peuvent nous concerner.

Les managers sont parfaitement aux courants.

Cdt,

[baptom76]

Merci pour le message.
Je le prends avec joie, ça me rappelle pourquoi je suis arrivé à ce niveau en tant qu’autodidacte.
Et j’ai déjà pris de nouveau RDV.

[baptom76]

Qui sont-ils ? Le lien que vous avez n’est pas clair.

Un ingénieur Système et sécurité réseau Et un administrateur système.

Qui prend les décisions ?

une “chaine” de commandement (monde pompier).

• les problèmes évoqués sont-ils réels et justifiés ou est-ce que c’est de la mauvaise foi ?
  (Pour “Linux ne fonctionne pas en entreprise”, on connait déjà la réponse ; pour le changement d’IP, tu peux juste leur dire “IPv6” pour leur mettre la pression, certains risquent de s’évanouir )

• Est-ce que tu peux faire quelque pour que le changement soit moins douloureux ? (parfois dev un petit outil, un wrapper, ou que sais-je peut aider à faire la transition)

Changement IPV4 en IPV6 (séparation des serveurs, poste client, matériels spécifiques (boite à clé…)) déjà un bon début
Suite à vos messages, je repends toute la démarche à 0 du bastion pour voir ce qui n’a pas été compris.

[jl-m]

Pour avoir aussi une casquette sécu, c’est un domaine ou les résistances sont fortes

Mon expérience dans une structure de taille moyenne, c’est 70% d’écoute, d’accompagnement au changement, de formation, d’écriture de rapports, de présentations concrètes des risques et … 30% de technique.

L’un des intervenants de l’excellent podcast NoLimitSécu parlait, il y a quelques années de sortir de la zone de la honte. Et c’est exactement ce que l’on cherche à faire, avec des règles simples et faciles à mettre en place. Comme dans le DevOps, on fait de l’amélioration continue et on avance, même malgré des refus de certains.

Pour les réfractaires, on n’oblige en rien (les injonctions ce n’est pas du tout dans la culture dans mon environnement), on les laisse juste de côté. On reviendra vers eux plus tard quand ils seront isolés et que les résistances se seront estompées.

On pratique aussi les réunions techniques (il doit certainement y avoir un mot anglais pour désigner ça) en petit comité. Les gens arrivent avec des résistances ou des problèmes concrets, nous les démontrent devant leur PC
On trouve comment les résoudre ou un contournement acceptable et on le fait… en direct devant eux sur notre PC autant que faire se peut. Ça aide à établir une confiance et une collaboration. C’est probablement un attendu du mouvement DevOps, on n’a pas inventé l’eau chaude. Le fait est que c’est simple et ça marche.