On nous demande d'envoyer nos logs à un SOC — à notre échelle, quel département ou profil doit gérer ça ?

Si vous mettez tout sur le dos des admins sys, au bout d'un mois tout le monde se rejettera la faute. Le sysadmin balance les logs sans regarder, le SOC râle en disant « il manque des logs », et le client se retrouve au milieu. Il faut absolument au moins un coordinateur qui s'y connaît en sécu.

En transférant les données des serveurs via syslog ou un agent, pensez à calculer la bande passante et la charge CPU sur les machines. L'équipe système peut s'en occuper, mais la synchronisation des horodatages et le chiffrement des flux demandent une vraie rigueur.

On est passés par là avec une équipe de 40 personnes. On a pris 20h/mois de consulting sécurité externe, ça nous coûtait environ 18.000 TL par mois. En y consacrant seulement 4h par semaine de notre admin sys, on a pu tout cadrer proprement.

N'envoyez pas vos logs à la va-vite juste pour faire plaisir au client. La plupart des SOC facturent un supplément pour chaque log inutile ingéré. Si vous ne cadrez pas strictement le périmètre des systèmes à journaliser, vous allez vous retrouver avec des factures monstrueuses à la fin du mois.

Quels logs votre client exige-t-il exactement ? Uniquement l'OS et le pare-feu, ou les requêtes en base de données et les activités in-app sont aussi dans le périmètre ?

Mettez en place une matrice d'escalade tout de suite. Si le SOC appelle en pleine nuit, ils réveillent qui ? 1) L'admin sys, 2) Le lead dev, 3) Le DG ? Ne commencez pas l'intégration sans avoir acté ça par écrit.

chez nous aussi ils avaient tout collé aux sysadmins au bout de deux mois les mecs voulaient démissionner. franchement faut clairement passer par un presta externe pour gérer ça.

En résumé : l'infra reste chez les admins sys, le code va aux dévs, mais pour le suivi des alertes et le pilotage du contrat, faites-vous impérativement accompagner par un expert externe.

C'est noté, merci. Un rapport de scan automatique n'est pas la même chose qu'un test d'intrusion.

Je vais essayer.

Enregistré. Tout va bien les trois premiers mois, les problèmes arrivent au quatrième.

Lors de la prise de décision, écrivez aussi le pire scénario, pas seulement le meilleur. Corrigez-moi si je me trompe.

exact.

Laissez-moi détailler l'aspect technique. Si vous obtenez trois réponses différentes sur un sujet, la question est mal posée.

Je vais résumer le sujet, car plusieurs réponses différentes ont été données. Les décisions hâtives finissent par être corrigées six mois plus tard.

J'y pensais aussi. Les environnements de test oubliés sont plus souvent des portes d'entrée que les systèmes de production.

Absolument. Si j'ajoute quelque chose : Prendre une mesure sans faire d'inventaire, c'est laisser une porte ouverte sans le savoir.

Avant de décider, regardez quelles données vous avez en main. J'espère que cela vous sera utile.

C'est exactement ça. Si c'est une première, commencez petit, l'échelle viendra plus tard.

Si vous écrivez le résultat ici, cela aidera aussi d'autres personnes.

C'est exactement ça. La plupart des incidents ne viennent pas d'une faille, mais d'un mot de passe divulgué.

La sécurité n'est pas absolue ; c'est rendre l'attaque trop coûteuse pour valoir l'effort. C'est mon avis, je ne l'écris pas comme une vérité absolue.