Nombre d'entre nous connaissent par cœur l'état de l'art des recommandations pour être cybersécurisé :

• Connaitre son SI
• Avoir des mots de passe forts
• Mettre à jour les machines
• Segmenter son réseau
• etc.

Elles sont faciles à énoncer mais souvent difficiles à mettre en place. Les clients nous font régulièrement part de leur désarroi quant à l'implémentation pratique de ces mesures :

• ‍"On a mis en place une CMDB mais les services connectent des trucs sans nous prévenir et ils ne les renseignent pas forcément dedans."
• ‍"On dit aux utilisateurs de choisir des mots de passe forts mais ils choisissent quand même des trucs prédictibles : Jérome2k22!"
• ‍"On voudrait bien migrer cette machine, mais elle héberge une application qui ne marche que sous Windows 7 et il n'y a pas de concurrent."
• ‍"Si on bloque les flux par défaut, on a 25 plaintes d'utilisateurs par jour !"

Et il est notamment flagrant que l'outillage logiciel à disposition n'est pas toujours à la hauteur : mettez à jour automatiquement les serveurs Windows et vous êtes assuré d'avoir au moins une panne générale par an. Faîtes confiance à l'évaluation de la robustesse des mots de passe de Windows et il laissera passer Avril2023!. Tentez un audit des permissions dans Active Directory et vous y serez encore dans un an.

À tel point que, pour certains, la sécurité informatique est un idéal inaccessible dont on doit tenter de s'approcher mais qu'il est illusoire d'espérer atteindre.
Et si je vous disais que quelqu'un l'a fait ?

Alors, je ne prétends pas qu'il s'agit d'une entreprise entièrement sécurisée, qui ne souffre d'aucun défaut.
Mais, il s'agit d'une entité qui résiste aux tests d'intrusion internes. C'est peut être un détail pour vous, mais pour moi ça veut dire beaucoup. Notamment quand on tient compte de l'aspect naturellement asymétrique de la sécurisation d'un réseau interne : même si l'équipe informatique a bien sécurisé 99,9% des machines, pour un attaquant, il suffit d'une seule qui ne le soit pas et ça peut suffire à tout compromettre.
Il est donc très rare qu'un réseau interne résiste à un test d'intrusion. Et ça signifie, à minima, que cette structure a un niveau de sécurité, non pas parfait, mais bien dimensionné à ses risques.

‍

Une approche "bottom-up" (comme disent les startupeurs)

Nous nous sommes dit que c'était l'occasion de vous livrer un témoignage à rebours des approches classiques. Plutôt que de passer en revue les bonnes pratiques et regarder s'ils les ont implémentées, nous allons leur demander à quoi ils doivent, selon eux, ce niveau de sécurité (ce qu'ils considèrent comme leurs 3 points forts).
Dans un second temps, nous leur demandons comment ils gèrent certains sujets que l'on sait être difficiles pour nos clients en général.

Ils ont amicalement répondu à notre demande, nous ont autorisé à livrer le contenu de cet échange, et nous les en remercions.
Nous alternerons entre des citations verbatim de leurs réponses (entre guillemets) et nos analyses.

Quelques particularité de notre bon élève
C'est un hôpital dédié aux soins psy. Donc presque pas d'automates, de biomédical, etc.
Ils ont environ 900 postes, 300 serveurs et 200 applications. 
Une équipe informatique de 3 personnes au pole infra (développement) et 2 personnes au pole service (gestion du parc, help desk, troubleshoot, etc.).
Donc ce n'est quand même pas un mince succès d'avoir sécurisé tout ça.
Ils utilisent la Cartes de Professionnels de Santé (CPS) pour authentifier les utilisateurs sur les postes.
Tout ne sera donc pas directement transposable à votre structure.

‍

Qu'est-ce qui, selon vous, fait que ça marche ?

Une culture de la sécurité, qui part de la base

"Le point fort numéro 1 c'est l'équipe."

"Avoir un RSSI qui fait la police avec les utilisateurs, c'est normal. Mais quand il doit aussi faire la police auprès des informaticiens, c'est perdu."
"Nous on est vraiment en security by design. Toute l'équipe informatique, quand elle développe, quand elle installe, pense sécurité. La prise en compte du sujet coule de source pour chacun."

Par l'expression "une culture qui part de la base", je ne parle donc pas des utilisateurs finaux (il ne faut pas rêver) mais de l'équipe. Comme ils le disent eux-même : la cybersécurité n'est pas un sujet poussé par la direction auprès de l'équipe, c'est l'inverse ! Et effectivement ça doit changer beaucoup de choses.
Mais je leur ai demandé si le fait d'avoir une équipe avec une telle culture de la cybersécurité était le résultat d'un hasard, d'un coup de chance, ou bien d'une démarche réfléchie.

"L'équipe a été formée autour de 3 personnes qui avaient un socle cybersécurité de manière essentiellement autodidacte."
Le premier est arrivé en 2005, recruté par la DSI de l'époque qui est maintenant DRH (et qui n'avait pas de connaissances particulières en informatique). Le second est arrivé en 2009 et a été débauché du rectorat par l'ancien RSI. Le dernier est arrivé en 2007 dans la structure médico-sociale (plus large que l'hôpital) et a définitivement intégré notre équipe en 2013."
"Il y a une cohésion d'équipe qui est forte. Ils ne sont pas que collègues, il y a beaucoup d'interactions, ça discute beaucoup, donc pas d'effet silo."

C'était donc en partie un coup de chance : 3 personnes qui partagent cette culture de la sécurité (ce qui est rare) qui postulent au même endroit.
Mais, souvent, on voit qu'il suffit d'un seul bon recrutement, pour qu'il en attire d'autres, ça crée un cercle vertueux. Tout comme, des fois, il suffit d'un départ, pour en entraîner des dizaines en cascade.
Or, réussir un bon recrutement, ce n'est pas forcément le plus dur. Il faut ensuite les faire rester. Et ça, ce n'était pas complètement dû au hasard, comme nous allons le voir dans le point suivant.

‍

De l'Open Source

"Ce qui fait aussi qu'on a réussi à maîtriser notre sécurité, c'est qu'on est très orientés open source. On n'a pas besoin d'acheter des solutions commerciales, car on a les compétences en interne. Et ça va même plus loin : si on prenait des solutions commerciales, on aurait des départs."
"Pour maintenir ce niveau de sécurité, il me faut des gens compétents, mais les gens compétents ne restent pas si c'est pour faire de la gestion de prestataires."

Voilà une opinion impopulaire dans beaucoup d'entreprises, mais que je partage fortement !

La remarque est intéressante car elle révèle un phénomène de cercle vertueux/vicieux qui a lieu dans de nombreuses entreprises et que beaucoup d'acteurs ne sont pas prêts à entendre.
Les entreprises renoncent généralement à utiliser de l'open source car elles estiment ne pas avoir assez de compétences en interne. Alors que c'est justement en choisissant de l'open source qu'on attire des compétences en interne.
Donc ceux qui prennent des boîtes noires, par manque de compétences en interne, déplorent des effets dont ils chérissent les causes.
C'est un peu plus compliqué en réalité car, qui est arrivé en premier, de l’œuf ou de la poule, de la compétence interne ou de l'open source, je ne saurais le dire. Mais il demeure que l'un engendre l'autre qui réegendre le premier.
Ce qui est source d'épanouissement, pour un informaticien, c'est d'obtenir de l'expertise sur différents sujets. Faire du baby-sitting de solutions commerciales très fermées ne le permet pas.

Pour nos fidèles lecteurs, vous savez qu'un des principes fondamentaux du security by design, c'est la conception ouverte (open design). Les boîtes noires se prêtent mal à la sécurité (quoi que peuvent en dire les éditeurs de ces trucs).
Chez Astar nous favorisons autant que possible les solutions open source chez nos clients : pfsense, Linux, arachni, ... et j'étais donc positivement surpris de cette mention.

‍

Par défaut : rien ne passe

"Notre deuxième point fort c'est le réseau. Le principe chez nous c'est «tout ce qui n'est pas explicitement autorisé est interdit»."

Alors c'est un très beau principe, et je suis le premier à en faire la promotion auprès des clients, mais j'ai rarement vu son application sans heurt. Comment ont-ils fait ?

"Ce n'est pas sans coût. La DSI sait que chez nous, rien n'est simple (et on se fait parfois un peu détester pour ça). Dès qu'il faut déployer un nouvel outil, c'est un long chemin, car de base il ne peut dialoguer avec rien. Ensuite, pour recueillir ses besoins d'accès, c'est compliqué car les prestataires et intégrateurs, souvent, ne connaissent pas bien leur produit. Et quand ils sont capables de les donner, des fois c'est délirant (des plages de 10 000 ports à ouvrir). Donc il y a de la négociation. Et même quand on a décidé de donner un accès, on peut être nous-même surpris : «ah oui il y a cette règle qui bloque aussi, on y avait pas pensé..»."
"Mais c'est surtout la mise en place qui est difficile (2 à 3 fois plus longue qu'ailleurs). Une fois que c'est passé, ça tourne sans problème."
"Sécurité et simplicité ne fonctionnent pas bien ensemble. Mais c'est accepté car on a les résultats derrière."

J'étais un peu déçu d'entendre cette dernière phrase car, chez Astar, nous essayons de promouvoir une approche d'une sécurité simple, même si nous savons que sur plusieurs sujets ce n'est pas encore faisable. Ça fait donc toujours un peu mal au cœur d'entendre toutes les difficultés que subissent ceux qui veulent bien faire.

Mais ce qu'on peut dire, en gros, ce n'est pas qu'ils ont moins de résistances qu'ailleurs pour appliquer cette règle (rien ne passe par défaut), c'est qu'ils tiennent bon face à ces résistances.
Ils n'ont pas moins de difficultés qu'ailleurs à appliquer cette règle mais ils acceptent ces difficultés en jugeant qu'elles sont nécessaires.

Mais alors, avec une telle approche et une telle réputation interne, ne craignent-ils pas que les services essayent de les bypasser et que ça fasse exploser le shadow IT ?

"Là c'est très simple : quand on n'est pas au courant, y a pas d'internet, y a rien"
"Ils ont installé un matériel biomédical, y a pas longtemps, sans nous tenir au courant. Ils ont du lui mettre sa propre box. Du coup, il n'est pas sur notre réseau, nous ça nous va."

Donc ils ont réussi à construire un réseau avec suffisamment de protections pour ne pas avoir de "passagers clandestins". À quoi ça ressemble de plus prêt ?

"On a 600 VLan répertoriés. Le maître mot c'est «on segmente !». Par bâtiment, par destination, par prestataire, ... Chaque usage a son VLan, ça nous permet de surveiller tous les flux qui passent.
"DMZ publiques, DMZ privée, réseau d'admin, réseau des switches, réseau des ESX, réseau des imprimantes, ..."
"Filtrage des machines par leur adresse MAC, via freeradius. Wifi en 802.1X en public ou en interne."
"Chez nous le ciel est dégagé : pas de cloud, on contrôle tout."
"Tout passe par le réseau. Celui qui s'en occupe est notre plus grande force et notre plus grande faiblesse s'il partait"

‍Tout ça est très intéressant car la segmentation du réseau est une mesure de protection que j'observe, au final, assez peu chez les clients (ou bien à un niveau rudimentaire). Or, effectivement, le réseau est ce qui va faire la différence entre "j'ai un poste infecté" et "tout le SI est infecté".
Pour des menaces type ransomware, il est difficile d'empêcher l'accès réseau au serveur de fichiers, puisque le poste en a besoin. Par contre, l'empêcher de trouver le serveur de sauvegarde, l'empêcher d'exploiter des vulnérabilités sur les serveurs, etc. on peut le faire via le réseau et c'est "game changer".

Donc la leçon à tirer ici est que nous sous-estimons probablement tous la puissance d'un réseau très étanche.

‍

Pas de mots de passe

‍"Le point fort numéro 3 : plus personne n'est administrateur, plus de compte non nominatif, plus de mot de passe faibles."

En fait, via la carte CPS, les utilisateurs n'ont plus besoin de connaître leur mot de passe (qui est donc aléatoire et très long), ils doivent seulement retenir le PIN de la carte.
Le scénario d'un compte compromis par mot de passe faible est donc tout bonnement exclu (aucune attaque par force brute ne peut trouver un mot de passe aléatoire de 25 caractères). Trouver le code PIN de la carte ne vous sert à rien sans la carte (double facteur). Les utilisateurs ne le choisissent pas (donc pas de 0000, 1234, 8888, ...) et l'attaquant n'a que 3 essais avant de bloquer la carte.

"Ils oublient leur carte ou leur code. C'est le plus gros truc à gérer."

En gros la carte CPS ça existe depuis longtemps et ça a des capacités d'authentification, mais rien n'oblige les établissements de santé à les utiliser pour cet usage. Ici ils ont fait le choix de profiter de cette possibilité technique. Pour le personnel qui n'est pas soignant, ils ont des cartes appelées Cartes Professionnelles d'Établissement. Elles marchent comme la CPS mais la différence c'est que c'est l'établissement qui gère la délivrance, la gestion et le décomissionnement de celles-ci.

Alors c'est vrai que c'est un autre ordre de grandeur niveau sécurité, mais ça a la réputation d'être lourd à mettre en place : changement d'habitude pour les utilisateurs, lecteurs de carte à puce, applications non compatibles, ...

"Les utilisateurs ne sont pas une source de plainte significative. Le combat le plus laborieux a été de faire accepter la carte à puce, mais c'était il y a 10 ans. Depuis on n'a pas vraiment de problème avec eux"
"La carte vérifie le PIN de l'utilisateur, mais ensuite tous les échanges avec l'AD se font avec le mot de passe. L'applicatif se charge de détecter tous les champs password et de les remplir."
"La carte CPS est directement utilisée par certains service SaaS. Pour les applications internes, on a un proxy applicatif qui centralise tout. Les users sont authentifiés par SSO (CAS) et le proxy utilise le mot de passe de l'utilisateur (que le proxy connait) pour s'authentifier auprès de l'application, pour l'utilisateur"

Donc, ce n'est pas une sinécure à mettre en place : il faut acheter des cartes à puces, des lecteurs de cartes à puce (puis plus tard on choisit des postes avec lecteur intégré), mettre en place une architecture de SSO assez complexe, sécuriser à fond le proxy applicatif, etc.
Il y a aussi des avantages. Déjà pour l'utilisateur c'est plus simple comme habitude d'utiliser une carte à puce avec PIN (il le fait au quotidien avec sa carte bancaire). Deuxièmement, de nos jours, avec les yubikeys et autres alternatives, pas forcément besoin de lecteur de carte à puce et ça marche sur smartphone, sur PC, et même sur serveur (comme HSM).
Et les bénéfices sont assez clairs. Plus de mots de passe faibles, un contrôle sur les protocoles applicatifs (via le proxy applicatif), plus de risque de vol de mot de passe, etc. Ceci combiné aux restrictions réseau, il reste vraiment peu de surface d'attaque.

Cette mesure a aussi un avantage à un plus haut niveau conceptuel.
Chez Astar nous distinguons les bonnes mesures de sécurité, celles qui sont "user agnostic", des mauvaises mesures de sécurité, "user dependant". Car nous croyons que la bonne sécurité, c'est celle qui se fait oublier. 
Il y a des domaines où l'on sait mettre en place de la sécurité "qui ne se voit pas", qui ne gêne en rien l'usage et qui ne dépend donc pas du fait que les utilisateurs respectent telle ou telle consigne, mais qui va, pourtant, bien gêner les attaquants (par exemple mettre les postes utilisateurs dans un Private Vlan).
Il ne s'agit pas là de tomber dans le poncif éculé du "le plus gros risque est entre la chaise et le clavier". Mais si votre sécurité dépend du fait que les utilisateurs respectent une consigne, vous planifiez votre échec. Aucun humain n'est infaillible, et donc plus vous avez d'utilisateurs, plus souvent vous serez confronté à des trous dans la raquette. Une bonne stratégie de sécurité considère les utilisateurs comme une aide et non pas comme une base.
On ne sait pas encore faire de la sécurité "user agnostic" dans tous les domaines, donc ce n'est pas un paradigme définitif. Mais en supprimant les mots de passe choisis par les utilisateurs, on s'affranchit d'un pilier instable dans la sécurité. En effet, compter sur les utilisateurs, pour choisir des bons mots de passe, peut marcher pour 99% d'entre eux. Mais pour un adversaire, il suffit d'un seul qui ne l'a pas fait pour obtenir un accès.
Dans cet établissement, les utilisateurs ne peuvent pas faire de mal, à leur insu, aussi facilement qu'avec un mot de passe. S'ils perdent la carte : pas grave, on la révoque et de toute façon sans le PIN, elle est inutilisable. S'ils révèlent le PIN (ou le notent sur un post-it) : pas grave, sans la carte le PIN est inutilisable. S'ils perdent la carte et qu'ils avaient marqué le PIN dessus : bon c'est pas terrible mais comme sans cette carte, ils ne peuvent plus se connecter eux-même (grosse différence avec un mot de passe révélé), ils vont bien devoir en avertir la DSI, qui va pouvoir révoquer la carte. Donc la fenêtre d'accès pour un adversaire serait courte, à l'inverse d'une divulgation de mot de passe.

Donc en résumé, leur triptyque c'est l'internalisation des compétences, le verrouillage par défaut et l'évacuation du facteur humain.

Maintenant, comment se débrouillent-ils face aux challenges "classiques" des équipes informatiques ?
‍

Les défis

J'ai abordé avec eux 4 thèmes qui me semblent être des défis difficiles pour les entreprises

• La gouvernance : sans budget, c'est dur de faire de la sécurité
• La cartographie : on ne peut sécuriser que ce qu'on connait
• MCS : appliquer les mises à jour de sécurité sans casser le parc, gérer les éléments obsolescents
• La détection : les SIEM et les SOC sont très à la mode mais souvent le ticket d'entrée se compte en dizaines de milliers d'euros et puis détecter ça suffit pas

‍

Gouvernance

C'est souvent dans ce domaine qu'on trouve les premières limites.

Si la direction ne comprend pas les enjeux, n'accepte pas que l'usage de l'outil informatique puisse être rendu plus complexe par certaines mesures de sécurité et ne donne pas de budget suffisant ... ça va être dur de faire des miracles.

Donc première question : quel est le budget informatique / sécurité informatique ?

"2%. On n'a pas un budget énorme. Beaucoup d'open source et un DSI qui est «geek» et qui est DAF aussi, ça aide car il négocie beaucoup. Il n'y a pas de distinction entre le budget info et le budget secu".
"Le RSSI n'a pas à faire acter des choses fortes par le directeur. Notamment car les résultats des pentests ne montrent rien de majeur à faire (essentiellement des modifications marginales), ça ne nécessite pas de négocier des budgets. Les fois où ça a du arriver, c'était négocié avec le DSI et c'est passé. Maintenant on a une maturité qui nous permet d'être autonomes."
"À 95% notre niveau de sécurité on le doit aux personnes"

OK donc, là, ils sont plutôt en mode croisière. Pas de gros achat nécessaire pour changer de ligue, juste maintenir le niveau actuel qui est satisfaisant.
Mais pour atteindre ce niveau de sécurité, il a probablement fallu faire des investissements dans le passé. Est-ce que ça a été un cheminement difficile ?

"Le principal combat a été autour du financement de la seconde salle serveur et peut-être aussi la virtualisation."

Troisième question, comment ça se passe avec la direction, notamment le fait d'être aussi pointilleux lors des phases d'intégrations (les métiers doivent se plaindre je présume) ? Est-ce qu'ils doivent justifier leur position régulièrement auprès du directeur ?

"Vu qu'on fait nos preuves, qu'on n'est pas une source de risque, la direction ne s'occupe pas du détail de notre fonctionnement, ils ont des sujets plus prioritaires."
"On se bat pour que les synthèses managériales des audits soient vraiment compréhensibles par les directeurs. Notamment avec des indicateurs du niveau moyen des autres CH, qui montrent qu'on est largement devant."
"On fait un comité sécurité et une bilatérale par an avec le directeur. On présente les résultats d'audit, on fait des retex, on fait acter des mesures supplémentaires pour verrouiller davantage, et ça s'arrête là."
"On aussi l'avantage de ne pas avoir de chantage à la vie à la mort dans notre domaine (psy). Ce qu'on a mis en place ici ce n'est pas transposable facilement dans un hôpital MCO (Medecine Chirurgie Obstétrique)"

Bon là aussi on a l'interrogation de l’œuf et de la poule. Est-ce que le bon niveau de sécurité est arrivé avant ou après la confiance de la direction dans les équipes ? Difficile à dire.

‍

Cartographie

Connaître son SI, c'est le début de la sécurité. On ne sécurise que ce que l'on sait être dans son réseau.
Le shadow IT est un angle mort qui peut coûter cher quand il est exploité par un pirate. Pour l'éviter il faut une base complète des éléments du SI, avec la traditionnelle difficulté à choisir entre une alimentation automatique ou manuelle.
Le plus souvent on observe des entreprises où les cartographies sont éclatées entre plusieurs outils, avec des champs non renseignés, maintenues à jour de manière opportuniste, etc.

"On est moitié automatique, moitié manuel." 
"Déjà, tout ce qui arrive sur le réseau passe par nous, sans quoi il n'accède à rien. Si quelqu'un se branchait sur une prise sans nous le dire, elle ne serait probablement même pas brassée. Et même si c'était le cas, sa machine ne sera pas reconnue et ne pourrait parler avec rien."

La cartographie c'est aussi ce qui permet de répondre au cas classique : il y a une alerte du CERT-FR sur Nextcloud 22.0.4, est-ce qu'on a des nextcloud dans notre réseau et si oui, dans quelles version ? Et pouvoir y répondre en quelques minutes (et pas en quelques heures) et pas en mode téléphone arabe.

"On utilise Eyes On Network : inventaire + supervision (OCS invetory + GLPI)"
"Tous les PC sont déclarés dans GLPI au moment du master."
"Pour les équipements réseau on a le meme firmware partout, le réseau est homogène."

Dans le SI, il y a aussi les utilisateurs. On voit souvent que les DSI peinent à suivre les évolutions RH : compte non supprimé au départ d'un employé, méconnaissance des accès qu'est censé posséder un utilisateur, ...

"Les RH doivent fournir une matrice d'habilitation. Ça a été dur à obtenir." 
"Il y a un connecteur entre la base RH et l'AD. ça gère bien les départs et les changements d'habilitations."

‍

MCS

Le Maintien en Conditions de Sécurité (MCS) est LE nerf de la guerre. Avoir appliqué les patch sur 99% des machines c'est déjà bien difficile, mais en plus c'est ingrat, car un adversaire pourra toujours utiliser le 1% restant comme pivot pour compromettre le reste. Il y a énormément de cas d'APT documentés où une faille non patchée a été utilisée comme levier décisif par les attaquants.

Or, la réponse à ce défi ne peut pas être simplement "ben mettez à jour vos machines".
Déjà, il y a le problème de l'instabilité des mises à jour Windows : si vous appliquez aveuglément tous les correctifs de sécurité, 2 fois par an vous aurez à gérer une foule de serveurs en carafe.
Ensuite il y a les angles morts des mises à jour. Par exemple sur Windows, qui est un système non packagé (à l'inverse de Debian ou Ubuntu), quand vous appliquez les mise à jour, ça concerne le système et tous les trucs Microsoft : IE, Office, MSSQL, IIS, ... mais pas les logiciels tiers : lecteur PDF, Firefox/Chrome, Winzip, VLC, etc. Or ces programmes sont souvent ciblés par les adversaire (PDF vérolé, site web piégé, ...). Il faut donc un moyen spécifique pour tout ce qui est installé en plus du système.

Est-ce que vous avez eu à gérer de la vétusté : des serveurs complètement obsolètes qu'on n'arrive pas à remplacer, etc. Et est-ce que vous en avez encore ?

"Oui il y avait un héritage : réseau à plat, serveurs vétustes, etc."
"Coté postes, pas d'obsolescence. Il peut y avoir quelques vieux trucs, sur des réseaux à part, très isolés."
"Coté serveur c'est plus compliqué. Du coup on les isole : hors domaine, sur un réseau à part."

Il y a un problème récurrent avec les équipements administrés par des prestataires/fournisseurs. 
Des fois le MCS n'est pas compris dans le prix de la license. On se retrouve avec un machine obsolète, très facilement attaquable mais sur laquelle on n'a pas la main (boîte noire).
On voudrait imposer des exigences de cybersécurité dans le contrat mais on n'est pas assez gros pour négocier les conditions d'achat, on doit prendre sur étagère.
En plus, le service Achats et la DSI se parlent généralement peu, donc difficile d'essayer de mettre des exigences en amont.

"On a une boite noire. Mais elle est seule dans son coin, connectée à sa propre box. Si elle se fait pirater, tant pis pour elle, mais ce n'est pas chez nous."
"Sinon il n'y a rien de non contrôlé dans le réseau. Quand les fournisseurs demandent des accès, on étudie leur légitimité et si on ne sait pas ce qu'il y a dedans : on ne donne pas l'accès".
"Il n'y a pas de synergie Achats/DSI où l'on demanderait des exigences cybersécurité en amont. Mais justement c'est derrière, quand il faut intégrer, qu'on refuse d'accepter les configurations à risque. Peu importe les conditions d'achat. Là dessus le DSI nous suit. Donc ça prend du temps. C'est même arrivé que l'éditeur change sa conf pour se mettre en conformité avec nous."

Comment vous gérez les mises à jour des serveurs ? Préprod, échantillon, sélection des correctifs critiques uniquement, ...

"Windows : en WSUS. Le parc est en mise à jour automatique sur pratiquement tous les postes. On a déjà eu des effets de bord, mais c'est moins d'une fois par an.
"Les serveurs sont en mise à jour manuelle. Quelques serveurs servent de test et une semaine ou deux après on applique sur le reste."
"On applique tous les patch, par lot. Quelques scripts aident à déployer toutes les maj, une fois validées, et ça gère les reboot (selon les heures déclarées comme non critiques)."
"Pour les logiciels hors Microsoft, on pousse les nouvelles versions via GPO ou scripts."
"Pour les Linux : on a du Debian, du Ubuntu et du CentOS. Debian et Ubuntu sont en maj auto. Pour CentOS, on teste manuellement."
"Ansible sert pour pousser les confs sur les linux."

Comment vous administrez les postes et serveurs ?

"On a un réseau d'admin et un VPN d'admin pour les opérations à distance."
"VNC pour les postes clients, RDP avec compte dédié pour les serveurs".
"Admin PC, Admin serveur, Admin domaine sont des comptes différents."
"On a LAPS pour les comptes admin locaux mais c'est en dernier recours. Le compte d'admin des postes est un compte domaine."
"On a un serveur d'administration pour le domaine (avec plein d'outils). On ne se connecte pas directement de nos machines en général".

‍

Détection

Faire de la détection ça demande souvent des logs d'événements. Et si on veut avoir une chance de coincer l'adversaire assez tôt dans son attaque, il faut des points d'observation au plus près : les postes utilisateurs, les serveurs, le pare-feu, ...
D'une part il est complexe de mettre en place autant d'agents d'observation, mais en plus stocker et parser les logs demandent une grosse machinerie.
Les offres de SIEM/SOC coûtent souvent un bras et promettent beaucoup de choses, tout en laissant sous le tapis un angle mort important : détecter, seul, ça sert à rien. Si vous avez un super SIEM top tiers, vous saurez exactement où le pirate est rentré, ce qu'il a fait, comment, ... mais vous aurez quand même un tas de cendres à la place du SI.

En somme, il est inutile d'investir à fond dans de la détection si vous n'avez pas les processus de réaction aux incidents derrière qui sont au moins aussi matures.

Qu'est-ce que vous avez en détection ?

"Un ELK pour les logs +Darktrace qui surveille ce qui se passe. Il fonctionne sur miroir de port et il y a une VM qui permet d'écouter les communications inter VM sur un ESX".

Est-ce que vous avez déjà eu à gérer des incidents de sécurité : intrusion, phishing, compromission d'un élément obsolète ?

"Des incidents, oui. Le pire ayant été un VSAN qui se met en lecture seule. Mais pas vraiment des attaques cyber."
"L'air de rien, les utilisateurs sont assez vigilants et il suffit d'un ou deux qui nous prévient d'un phishing et on a un outil pour aller sniper le mail en question dans toutes les boites mail".
"Et vu notre segmentation, on peut facilement isoler des bâtiments, des services, etc en coupant des ports sur des switches."

Effectivement la segmentation permet de pouvoir rapidement confiner des éléments compromis et ainsi de réduire la surface infectée.
Derrière, c'est autant de travail en moins pour la partie restauration. Et lorsqu'on coupe 2 ou 3 VLan sur 600, on empêche peu de personnes de travailler. Donc c'est plus indolore qu'un réseau à plat où tout le monde est au chômage technique à la première infection.

Conclusion

J'espère que cette interview très pragmatique vous aura été utile, ou au moins inspirante.
Elle n'est pas là pour démentir la théorie, mais pour ne pas se contenter de la théorie.
Et, en fait, cette remontée terrain nous montre plutôt que la théorie a juste. Pendant des années, on s'est moqué de l'ANSSI avec ses guides inapplicables (j'ai du le faire aussi une fois ou deux, je le confesse) : mettre des cartes à puce partout, dessiner des réseaux avec 15 000 firewalls, ... Bon, sans dire que tout est facile à mettre en place, le témoignage d'aujourd'hui montre qu'ils ont une bonne vision de ce qui doit être privilégié.

Ce dont il faut un peu plus se méfier c'est de la littérature sponsorisée. Elle représente une part majoritaire du volume des articles qui parlent de bonnes pratiques de sécurité, mais n'est pas vraiment impartiale et peut vous faire passer des vessies pour des lanternes.