Reprise du message précédent :

Avoue tu es jaloux, les cryptos génèrent plus de flouz que la sécurité

 
Ca me fait bosser, et perso je préfère pouvoir dormir tranquille
 
(je peux déjà plus me regarder dans une glace par contre, ça c'est fait).

Ca donne envie de se lancer dans le business

enfin une idée pour monter sa boite, je prends

 
Les basiques sont nettement moins une question de budget que de compétences.  
Et franchement avec des machines à jour, un socle durci selon les bonnes pratiques dispo partout, un firewall perimetrique correctement configuré, du log exporté (ça c’est absolument central, même sur un nas pourrave dans un coin au pire) et du backup hors ligne, tu te prémunis de l’essentiel des attaques.  
Pour les autres effectivement faut commencer à avoir du tooling lourd et des compétences plus pointues.  
Mais les bases c’est loin d’être cher et c’est massivement de l’amélioration continue.

 
Je suis pas sur de comprendre ce point, tu peux préciser ? (utilité, a quel moment ?)
 
Ah, j'imagine que le log te permet aprés attaque de reperer ce qui a été attaqué précisément ?

 
Oui et non car le but d'une boite c'est de fournir un service, pas la sécurité. Ta boite à déjà plein d'infra et d'outils pas du tout sécure et donc toi t'arrive et s'ils appliquent ta stratégie, plus rien ne marche. Ils doivent donc investir fortement pour avoir quelque chose qui tient la route.
 
Faut le faire hein. Mais c'est pas gratuit. Là ou je bosse on est habitué, on est certifié carte de crédit, mais ta encore des trous.  
 
Les problémes de sécurité sont dans les détails et c'est une tache sans fin.
 
Sans oublier que plus t'es sécure plus tout coûte cher et plus la productivité de tes ingénieurs baisse.
 
Par exemple ma soeur n'est pas admin sur son PC et bien sûr ne peut pas lancer de container et internet et fortement restreint. Elle va pas avoir la même productivité que dans la boite ou je bosse ou tous les devs sont admins de leur PC et peuvent installer tous les outils dont il ont besoin et surfer à fond sur le net pour chercher la doc...
 
Perso je me suis appercu que pour coder, l'outil numéro 1 que j'utilisais, au delà de l'IDE, c'est google. Et ça a l'air de rien mais je crois que c'est un des trucs qui m'a permis d'évoluer dans ma boite et passer Principal Engineer. Le fait d'aller chercher l'info là ou elle est et de l'intégrer dans mon workflow quotidien. Je dois faire des dizaines à centaines de recherche par jour sur le net.
 
Et quand je veux tester un serveur ou une techno, je DL l'image docker, on en parle plus.
 
Ma soeur elle doit faire une demande officielle, justifier pendant 50000 ans, et elle l'aura peut être dans un mois et 1 fois sur 2, ça marche pas.

Tu ne garantis pas la sécu si tu laisses des personnes admin de leur poste.
 
Pour la simple et bonne raison que :
 
Tu ne maîtrises plus le patch management.
Tu ne maîtrises plus ton environnement.
 

T'a testé Solarwind récemment ? Ça a l'air d'un super produit

Si tu vois pas le problème à faire ça sur un poste de travail du SI, qui plus est où tu es administrateur, tu devrais quand même te poser des questions.

Par contre, ta boîte devrait te fournir des environnements de Sandbox, isolés, où faire ce genre de tests rapidement et avec des risques moindres.

 
Évidemment, c'est le même coût !
 
On est tous d'accord pour appliquer les "bonnes" pratiques mais on a tous (au moins) une bonne raison de ne pas le faire. Et l'ANSSI et Gloubiboulga pourront déclamer que c'est facile, rapide et pas cher, ça ne changera rien.

Non mais le poste admin, c'est quand même plutôt simple à gérer.
 
Un banc de génération, surtout sur Windows, ça doit pouvoir s'envisager
 
Chez nous on en est au point où le C€rt envisage de hacker les postes pour les mettre à jour

On parle pas forcément d'un super cloud privé openstack bling bling.
Un hyperviseur dans un coin dans une zone réseau spécifique ça peut suffire. Voir juste quelques vlans dédiés.

Y'a pleeeeins de solutions intermédiaires entre "olol toutes les équipes IT sont admin sur leurs postes, les dev DLs tout et n'importe quoi et le test en local" et "tout le SI de la boîte est DR, classe 2, full airgap, avec soc pdis, admin padm, audits passi trimestriels et cert pris en 3*8 prêt à intervenir".
Mais oui, retirer les droits d'admin locaux, ça fait partie des premiers steps. Apprendre aux gens à pas DL n'importe quoi et l'exécuter n'importe où c'est pas très loin non plus.

Y'a un gros fantasme collectif que la sécu ça ne peut être qu'extremiste et bloquant pour le métier. C'est dommage pour tout le monde.

XaT, tes devoirs pour le weekend, c'est de trouver la définition des acronymes

Si t'as pas la fibre, ça le fait pas...
A+,

 
Perso je pense l'inverse, ta sécurité est naze si elle est dépendante de savoir si tes utilisateurs sont admin ou pas, de quel systéme d'exploitation ils dépendent et quels logiciels sont installés.
 
T'aura toujours des gens malveillant qui vont arriver à se connecter au réseau avec une machine compromise par exemple et qui auront les droits qu'ils veulent.
 
Ensuite si tu veux que tes devs puissent bosser et par exemple donc utiliser docker/kubernetes, va bien falloir soit leur permettre en local, soit leur donner les infras de tests qui vont bien. Et là ils auront par définition beaucoup de droits.
 
Ca n'empéche d'ailleur pas de restreindre les choix. Par exemple nous tu as windows 10 ou certaines version gérées d'ubuntu ou macos... Et tout les updates sont gérés par l'IT bien sûr et un certain nombre de réglages sont forcés (comme l'application des patch sous windows).
 

 
Chez nous c'est standard, les devs sont admis, ils peuvent tester leur container en local, reproduire rapidement aussi.
 
Proposer du cloud à distance, c'est déjà mini doubler l'infra de test. On a donc dans les 5000 devs, il faudra donc fournir, 5000 systémes de tests managés. Je te laisser méditer sur le coût de ça hardware + administration.
 
Sans parler que t'aura pas la même productivité de toute façon.
 
Et sur ces systémes, tu va quand même faire tourner des codes arbitraires de containers de toute façon hein.
 
A l'inverse tes équipes sont-elles capable de ressencer les milliers d'applis/mdw utilisés par les dev, proposer des script d'installation automatique aux petits oignons dans toutes les version et tout sans ralentir personne ?
 
L'XP que j'en ai c'est que dés que t'es pas admin, tu peux plus faire grand chose, les équipes supports sensées t'aider et sont toujours à l'ouest et la moindre chose prend des moi et coute donc en productivité réélle des milliers à disaines de milliers d'euros perdus pour la boite.
 
Et les devs en question quand leur boite et relou et que le support suit pas, ils démissionnent. Donc en plus le taux d'employés compétants baisse.
 
A l'inverse si tu sais pas empécher une machine qui serait corrompue de pourrir ta sécurité, ta un gros probléme, car ça va arriver de toute façon.

Quand je lis ce débat jsuis content de pas avoir encore atteint la taille de grosse COGIP

https://zetter.substack.com/p/negot [...] en-to-play

Je suis pas sur que nombre de boites impactées en France suivent la best practice (remonter un réseau parallèle clean et reinstaller au propre).
A+,

on en parlait pas plus tard qu'hier, j'ai déjà vu faire mais je sais pas dans quelle mesure c'est fréquent

Bah déjà pour appliquer ça il faut savoir exactement ce qui est installé, et comment c'est configuré. La très grosse majorité des entreprises t'as des trucs fait à la main, sans aucune doc, par des mecs qui sont plus là.

Alors c'est super intéressant la définition d'acronyme ou encore d'abréviation, etc. On se trompe souvent ! Et ça s'imbrique c'est pas si facile

Si même toi tu t'y mets
J-15

C'est la première fois que je vois cette description.
C'est l'équivalent de tech lead ? Car si t'es le seul ingé sur 5000 devs, GG  

Ya une différence entre un ingé et un tech ?  

Ça peut justement être l'occasion de repartir sur quelque chose de plus propre/sécurisé.... Par contre faut pas espérer redémarrer en 2j

 
Oui pardon, comme la boite est assez cosmopolite/internationnalle, il utilisent des termes anglo saxon pour les postes.
 
Chez nous, le principal (software) engineer peut faire beaucoup de choses, en pratique je me retrouve à:
- former les autres devs/ingénieurs et les aider à progresser/monter en compétance
- faire du design et de l'architecture, des études sur les nouvelles technos un peu comme un architecte
- faire évoluer les process, promouvoir les best practices et pousser les évolutions (passage au cloud, nouvelle version d'un language, automatisation des builds ou du releasing...).
- faire du développement classique.
 
Attention, je suis pas un ops ou un gus externe. C'est vraiment cette idée de tech lead ou senior dev qui a plus de bouteille et qui essaye de pousser à ce que les choses évoluent dans le bon sen en plus de faire du dev classique. Et pour tout ce qui va être build/release je vais bosser avec les équipes qui s'occupent de ça ainsi qu'avec les gens qui gérent les opérations.
 
J'apprécie de garder les mains dans le cambouis. C'est plus facile à vendre pour aller ans les équipes, et ça assure que tu fasse pas trop n'importe quoi car tu subit les process aussi. Mais clairement faut savoir déléguer pour avoir quand même moins de taches de dev qu'un dev qui fait que ça.

 
Perso je pousse à fond sur terraform/ansible/containers:kubernetes et gitops. C'est en cours de migration chez nous, on aide les ops à évoluer vers ce modéle et on passe aussi sur des technos cloud et du multi région. Ca rajoute aussi pas mal de challenge bien sûr.
 
Mais si tes scripts de config et d'install sont sur git, avec des PR pour chaque modifs et validés bah déjà t'évite les snowflake servers, les archis qui sortent de nulle part et in-reproductibles. Tu peux valider tout ça en test facilement vu qu'en gros c'est les même scripts.
 
C'est aussi l'avantage du cloud, avec des containers que tu stoppe et démare sans arrêt, ça t'oblige à être réglo sur ton infra et tes applications.

Bah c'est juste un titre associé à un grade dans une échelle interne.
 
Dans la plupart des boîtes qui permettent une vraie progression pour les rôles techniques tu as quelque chose du genre:
 
junior* -> mid-level -> senior -> lead ou staff -> principal -> ...
 
*Junior c'est de plus en plus souvent implicite et pas en toutes lettres, pour pas les froisser j'imagine.
Les promotions vont plus ou moins vite, y a parfois des niveaux intermédiaires (par exemple senior staff), ça a plus ou moins de poids suivant la boîte.
 
Ingénieur n'a aucune valeur ou définition légale dans la plupart des pays, les grands groupes utilisent ça comme ils veulent.
 
Malgré l'orthographe douteuse de foudres, il a parfaitement raison. Tu gères pas des centaines ou milliers de devs comme des secrétaires ou tes employés côté business qui font du Outlook / Excel / Powerpoint.

 
on a morflé y a pas longtemps, j'ai failli t'appeler pour que tu viennes chez nous à J+0, puis je me suis dit que tu te serais barré en courant après quelques minutes d'explication de contexte (gue-guerre politique entre les branches et donc les SI, zero pilotage, mode chacun sa gueule, y a t-il un pilote dans l'avion, etc etc).
 
tu sais où je bosse, je pense que t'as du entendre parler de ce petit problème.
 
la, on réfléchi à l'après, je rigole au vu de la façon dont les choses sont traitées, j'attends le retour de kick avec l'attaquant qui revient par la fenêtre 1 mois après.
 
pour mon périmètre, je vais voir si le patron serait ok pour avoir un audit de sécurité, histoire qu'il pige bien l'ampleur du "problème".
 
Si j'ai le go du chef, je te contacterais pour un audit de sécu, je suppose que tu en fais ?  

Cool à lire cette page, merci

Clair en tant que nouveau RSSI dans une administration depuis quelques semaines…
C’est inquiétant ou je suis, rapport d’audit non suivie d’effet en 2016, en 2018, attaque au mois de Mai 2021 sur la messagerie échange (qui servait à faire du minage) et le responsable informatique qui ne change MEAE pas le compte admin… tous les logs ont été effacé au 15 mai, et pour lui tout vas bien…
Et au passage, c’est le même mot de passe utilisé partout ou presque.
Le gars a 60 ans, en CDI dans l’administration, et en poste depuis 1996…

On a toujours fait comme ça avant  

 
Je me dis qu'a ne faire que des demi mesures, on n'a que les emmerdes (cote admin et user)
 
Par contre la formation et l'embauche de gens qui ont un cerveau et sont responsables, la je dis oui

Et du coup, quand vous allez vous prendre une bonne grosse attaque, c'est toi et tes devs qui vont remonter toute l'infra ? Parce que c'est bien de demander tous les droits, mais il faut avoir les devoirs qui vont avec.

Le rapport entre les machines des devs et l'infra?

BYOD

 
Bring Your Own Disaster ?  
 
Nouveau concept à creuser  

 
"C'est historique"

Non. A un moment donné, tu adoptes un niveau de sécurité en fonction des risques auxquels tu est exposé. Ça n'a pas de sens d'appliquer la même chose à la production d'armes nucléaires et à un plombier.

Admin + pas de filtrage web parceque tu comprend c'est chiant pour les devs, un jour, un dev prendra un keylogger ou un rat sur son poste, et paf ça fait un accès.
Le concept de la sécurité qui marche, c'est qu'elle est en profondeur. Si tu fait que du périmétrique, tu rates un gros morceau.
Et non, t'expose pas forcément toute l'Infra si un poste de dev se fait powner. Mais t'expose son poste, ses secrets, ses mails, le code qu'il fait (et qui peut se faire modifier du coup)...
Regarde Solarwind, la conséquence c'est pas un crypto, c'est du code sale chez tous les clients que personne n'a vu.

D'ailleurs quid d'avoir des Yubikey ou équivalent pour tous les devs ? Plus de MDP, si tu paumes une key, tu révoques et hop ?