Si la sécurité est intimement liée à l’application de bonnes pratiques, il n’en reste pas moins que ces dernières sont généralement implémentées par des humains. Or, la sécurité peut avoir mauvaise presse : l’activité présente un niveau de responsabilité critique qui peut être ingrat. Quand tout va bien, c’est normal et transparent. Quand ça va mal, le feu (des projecteurs) est rapidement orienté sur les identifiés sécu’, dont la réputation peut pâtir à terme. 

C’est pourquoi, dans cette édition #3 de la revue Sécurité, nous vous proposons quelques articles qui ont attiré notre attention, en lien avec l’intégration de la sécurité au sein des équipes.

Afin de motiver ses équipes, Keith Ibarguen, dans un article publié sur securityweek.com, fait état de plusieurs propositions pour donner du feedback à ses ingénieurs autour de la valeur ajoutée qu’ils apportent. L’objectif sous-jacent étant de donner du sens au travail accompli et un sentiment de but, de purpose.

Faire vivre son ikigai, sa raison d’être avec les 4 propositions de K. Ibarguen ?

La première proposition est de prendre du recul. Il peut arriver que l’on se laisse embarquer par diverses priorités au quotidien, et que la charge mentale engendrée rende plus difficile de prendre le temps de se rappeler pourquoi une security feature est développée ou non. S’arrêter pour bien décrire le contexte et la valeur ajoutée par chaque feature peut permettre de motiver ses équipes, et former un sentiment de cohésion en travaillant vers un but partagé.

A titre personnel, je suis d’accord : il m’est préférable de savoir pour quoi (= what for) je travaille plutôt que d’avoir la sensation d’être dans une nébuleuse éthérée de sprints réguliers et d’actions répétées dont je ne perçois pas le sens.

La deuxième proposition est d’instrumenter l’application et d’établir des métriques qui vont permettre de déterminer le taux d’adoption d’une feature. Ainsi, bénéficier d’un feedback technique peut permettre de confirmer (ou d’infirmer) les hypothèses avec lesquelles une feature a été développée, et de guider les prochaines décisions de développement : on garde, on garde pas, on fait mieux ? D’une certaine manière, on vient frôler les bénéfices apportés par l’A/B testing avec cette proposition.

La troisième proposition suggère de récupérer le feedback côté client (sprint review ?), et de réaliser l’équivalent d’un sprint retrospective, afin de faire profiter du retour d’information du client. Réalisée de manière constructive, cette “cérémonie” peut permettre de renforcer le sentiment de valeur d’un développeur s’il assimile le bénéfice retiré par le client qui utilise sa security feature. A noter que K. Ibarguen fait fort justement une mise en garde, à ne pas tomber dans le piège de vouloir forcément recréer ce qui a déjà marché et de tomber dans des patterns qui peuvent limiter l’innovation : ce n’est pas parce que cela a plu dans le passé que cela plaira dans le futur (note : il doit y avoir un nom de biais ou de loi… si quelqu’un peut me le donner…).

Quatrième et dernière proposition, de s’assurer que les buts, et donc les intérêts, des ingénieurs et ceux de l’organisation sont alignés. Pour ce faire, K. Ibarguen suggère de faire des réunions stratégiques, et de garder en tête que comme toute stratégie vit, change, évolue, il faut vérifier que celle-ci continue de coller avec les intérêts des ingénieurs, au risque peut-être, de voir moins d’engagement de leur part.

Chez Devoteam Revolve, tout comme K. Ibarguen certainement, l’humain tient une place significative au sein de l’organisation et de nos activités (cf. notre démarche HEAT ou bien le podcast HEAT en audio).

Entre autres choses, il serait difficile de travailler sur des technologies innovantes et la transformation numérique sans prendre en compte l’importance de comment apporter et conduire ce changement chez un client.

Chris Kranz, de Sysdig, a publié un article sur comment établir une culture DevSecOps au sein d’une entreprise. Selon lui, les freins majeurs dans l’adoption d’une telle culture, et dans la promotion du shift-left, sont notamment le manque de formation (en sécu pour les devops et en devops pour les secus), ainsi qu’un manque général d’implication dans la sécurité.

Afin de pallier ces deux problèmes et de casser les silos, il propose de faire comme un échange étudiant/linguistique entre les devops et les sécus. Si ces deux équipes ont un langage et une culture différente, quoi de mieux que de les faire voyager les uns chez les autres ?

C. Kranz suggère de faire vivre l’expérience de la sécurité aux devops, même à raison d’un jour par mois, et de faire vivre le devops aux secu : si possible un sprint entier pour faciliter une vision globale.

Au cours de l’échange, l’étudiant se mobilisera pour poser des questions, se séparera de son arrogance, gardera un esprit ouvert en laissant son propre job derrière soi et enfin, les bénéfices devront être accueillis en temps utile par le manager plutôt que de surveiller le retour sur investissement pour le temps accordé à l’étranger.

Pour aider le manager à aller au-delà de la perte potentielle de productivité d’un jour par mois, il mentionne la loi de Parkinson qui propose que le temps de travail grossit pour occuper toute la disponibilité qu’on lui accorde. Ainsi, même avec du temps en moins, on peut continuer à effectuer la charge de travail attribuée au sein de la période impartie (tip : ça ne marche que dans une certaine limite…).

Il formule également l’hypothèse que ce jour mensuel, ventilé sur le quotidien, représenterait l’équivalent de ce qui est perdu en context-switching ou interruption de collègue : bref, pas grand chose.

Par contre, du côté des bénéfices, cela permettrait, grâce à l’immersion dans les autres équipes, d’apprendre sur le tas, facilitant l’adoption de ce nouveau savoir, et de favoriser le shift-left. En mettant la sécurité dans les différents secteurs, celle-ci tendra à être prise en compte nativement et à faire partie du design (tout comme en mettant de la technologie dans plusieurs départements, l’IT se retrouve à faire partie des stratégies de toute entreprise ou presque).

Il poursuit par l’importance d’avoir des gens sensibilisés à la sécurité dans les équipes (security champion ?), et que la sécurité soit un vrai sujet initial, et non pas une pièce rapportée.

Enfin, pour lui, il existe un bénéfice dans le fait de créer du lien, voire des amitiés, et que cela contribue à la bonne ambiance générale.

Sur ce dernier point, au-delà du fait que je suis parfaitement d’accord, j’aurais envie d’ajouter que généralement, on a peur de ce que l’on ne connaît pas (écraser une araignée inoffensive, qui a déjà fait ça ?), et que mélanger les cultures ne peut que favoriser la communication et l’influence réciproque entre les adeptes de l’automatisation et ceux de la sécurité. Le meilleur des deux mondes.

Au final, je salue l’idée du programme étudiant, que l’on peut proposer (push) ou solliciter (pull). Je trouve l’image simple et pédagogique : il est facile de s’en faire une représentation partagée.

Et si partager une représentation peut être source de valeur, on peut néanmoins ne pas avoir envie de partager ses données. La prochaine fois, nous verrons comment faire rimer sécurité avec confidentialité.