Pour une posture efficace de la sécurité

Je travaille dans le domaine de l’IT depuis plus de 10 ans maintenant et j’ai côtoyé pas mal d’équipes "sécurité" au sein des entreprises dans lesquelles je suis passé. Je suis moi-même un "security guy" (Cloud Security Architect) depuis un peu plus d’un an.

Durant ces années, j’ai souvent constaté une posture bloquante des équipes sécurité, parfois même déconnectées du terrain, conduisant de fait à des ralentissements et tensions dans les projets.

Aujourd’hui, je vais vous présenter la posture que j’ai choisi d’adopter et vous expliquer pourquoi. Je vous donnerai aussi mon point de vue avec un peu de recul au bout d’un an.

Un peu d’historique

Dans la plupart des entreprises par lesquelles je suis passée, la sécurité est souvent un checkpoint obligatoire, mais pas forcément utile ou efficace… je m’explique.

Souvent, on sollicite cette équipe en fin de chaine pour :

• Faire un test d’intrusion sur une infrastructure
• Vérifier que le livrable est conforme
• Demander des "passe droits" spécifiques

De plus, on évite autant que possible de les solliciter, car on sait que le délai de réponse va être long, souvent en semaines.

Pour en ajouter une couche, j’ai souvent eu affaire à des personnes déconnectées de la réalité du terrain concernant :

• la maturité des équipes de réalisation concernant la cybersécurité
• l’outillage
• les besoins business
• les délais de livraison

Autant dire qu’on arrive souvent à un langage de sourd, chacun ne comprenant pas l’autre.

Moi-même, à mon arrivée dans ma mission, j’étais dans une posture où une barrière existait entre les dev/ops et la sécurité. Les premiers ne comprenant pas l’intérêt des mesures en train d’être mise en place.

Cette barrière crée de fait de la résistance au changement et ralentit donc la vélocité des équipes, en plus de mettre une ambiance pas forcément agréable.

Descendre de sa tour d’ivoire

L’un des points majeurs, comme je l’ai évoqué plus tôt, est la déconnexion des équipes opérationnelles (devops) et la sécurité.

L’une des premières choses que j’ai mise en place pour améliorer cette situation est d’organiser des points réguliers entre les ops et moi-même.

Dans ce modèle, les ops sont donc dans une posture d’"ambassadeur" de la sécurité. Cela ne signifie pas que je n’échange pas avec les équipes de développement, mais plutôt qu’il faut désigner un SPOC (Single Point Of Contact = Point de contact unique). Humainement, je ne peux pas m’adresser directement à 200 personnes.

En effet, le but de ce point est surtout d’être bidirectionnel. Cela permet :

• Que la sécurité puisse présenter en avance de phase sa feuille de route, en l’expliquant
• Que les équipes puissent remonter au plus tôt leurs inquiétudes, besoins ou blocages actuels
• De manière générale, cela améliore la communication entre les entités

De plus, prendre en compte les remontées des équipes "de terrain" permet aussi d’ajuster autant que possible l’outillage ou les règles de sécurité en train d’être mises en place.

Attention toutefois, le but n’est pas de justifier les choix, mais de les expliquer, il faut donc être dans une posture pédagogue, et non pas se braquer ou se mettre sur la défensive.

Zero trust… oui, mais pas que !

Je suis un adepte du modèle zero trust (un blogpost arrive bientôt sur le sujet), toutefois, je fais partie des personnes qui considèrent que c’est un modèle, une cible à atteindre, pas un objectif immédiat.

Le souci que j’ai souvent vu est une posture incohérente à ce sujet :

• Hardening trop dur : on empêche les équipes de travailler en mettant un cadre technique trop fort (par exemple, en ne donnant aucune autonomie sur une installation de logiciel)
• Ne pas être capable d’adapter une règle si elle est trop rigide (par exemple un filtrage réseau, ou un protocole incompatible)
• Se positionner en mode bloquant sur un projet, empêchant toute livraison

Mon approche est plus de me dire qu’il faut comprendre les contraintes techniques et opérationnelles des équipes pour voir comment on peut appliquer du mieux possible le zero trust.

Cela signifie :

• Que je tolère parfois de donner plus de droits que nécessaire temporairement pour permettre aux projets d’avancer
• Qu’il est nécessaire de faire confiance aux équipes
• Qu’il faut montrer que l’on est disponible pour répondre aux questions, et que l’on est dans une approche constructive, le but est de trouver une solution

Accompagner les projets plutôt que les bloquer

C’est le point sur lequel j’insiste souvent. Dans ma tête, la sécurité a pour but d’accompagner les projets du mieux possible. L’idée est donc :

• De documenter en amont autant que possible, pour que l’information soit partagée
• D’être disponible pour aider les équipes
• D’être à l’écoute des besoins des équipes
• Avoir une approche bienveillante
• D’être dans une démarche de conseil plutôt que d’"inspecteur des travaux finis"

Vous l’aurez compris, je suis complètement dans une approche DevSecOps, qui de mon point de vue permet d’être efficace.

Se positionner en tant qu’accompagnateur permet de plus de gagner du temps, en devenant un acteur du projet à part entière, cela permet d’être écouté, d’écouter et que les besoins de la sécurité soient pris en compte au plus tôt dans les projets.

Adopter cette posture permet aussi que les équipes deviennent des alliés plutôt que des adversaires à combattre.

Cela passe aussi par beaucoup de communication, comme je le dis souvent une grosse portion de mon travail quotidien est d’expliquer, de documenter. Plus l’information est claire et disponible, plus les règles associées seront adoptées.

Cela signifie aussi qu'un RSSI doit savoir s'entourer de personnes techniques pour accompagner au mieux les équipes. Pour rappel, le rôle d'un RSSI n'est pas tant technique qu'organisationnel.

En conclusion

J’applique moi-même les règles que j’ai évoquées plus tôt, et je dois admettre qu’en un an, j’ai vu les bénéfices directs :

• On me sollicite au début des prochains pour voir les points d’attention que je peux apporter
• Les décisions de la sécurité sont comprises (pas forcément acceptées, mais l’objectif est compris)
• Je ne suis plus vu comme étant un point bloquant

Mon approche vient sans doute de mon passé d’Ops, qui fait que je me suis moi-même retrouvé de l’autre côté de la barrière. Je suis donc plus à même de comprendre les problématiques auxquelles peuvent être confrontées les équipes sur le terrain.

Cela ne signifie pas que tout est rose, il y aura toujours des mécontents, toutefois au lieu d’être impliqué en fin de chaine, je suis devenu un acteur des projets.