La chronique du Cesin – Développements agiles : le RSSI acrobate

Parmi toutes les bonnes pratiques de sécurité que le RSSI doit diffuser dans son organisation, l’intégration de la sécurité dans le cycle de développement des applications est une mesure très complexe à faire adopter et à maintenir dans le temps.

Tout le monde comprend facilement qu’il est moins couteux et plus efficace de bien développer du premier coup, plutôt que d’être obligé de corriger les applications suite aux dysfonctionnement constatés par les utilisateurs. Et pourtant, même dans les très grandes organisations telles que des Ministères, les médias se font l’écho de scandales impactant dans leur travail ou leur vie familiale qui sont directement dus à des erreurs de développement. Les errances du logiciel Louvois gérant la paie des personnels militaires ou de l’application PNIJ ou Plateforme Nationale des Interceptions judiciaires en sont deux exemples récents.

Il en est de même de l’introduction, dès la conception et le développement, des mesures de sécurité ou de la protection des données personnelles. Le texte du règlement général pour la protection des données (RGPD) définit explicitement le « Privacy By Design » et les RSSI depuis bien longtemps prône le « Security By Design ». Alors pourquoi cela n’est-il pas encore la pratique de base ?

Plusieurs causes sont la source de ces pratiques et la première qui peut être mise en avant est la pression que subit le développeur pour remettre son travail dans les temps mentionnés dans le contrat. Ce temps souvent sous-estimé par les commerciaux pour que leur offre soit plus compétitive dans l’obtention d’un contrat. Pour respecter les délais les développeurs n’ont pas le temps de développer « sereinement » selon des bonnes pratiques et en vérifiant le bon codage de leurs programmes. L’exemple souvent donné est que lors d’une saisie de donnée le programmeur doit prévoir de vérifier que la valeur entrée par l’utilisateur n’est pas plus grande que la taille de la zone prévue pour la recevoir. Basique ! Néanmoins cela est souvent la cause du célèbre « buffer overflow » que des hackers utilisent pour injecter des codes malveillants.

Encore faut-il que les mesures de sécurité aient été bien spécifiées en amont et validées dans les spécifications détaillées de l’application. Certaines sociétés matures imposent au sein du cycle de développement qu’une fiche d’exigences sécurité soit remplie et validée par le RSSI.

Toujours dans les exigences temporelles pour correspondre aux attentes client, se développe de plus en plus des méthodes en rupture avec le cycle de développent en V ou les méthodes ITIL dans lesquelles les phases de développement (build) sont clairement séparées des phases de mise en production (run). Ce sont les méthodes dites Agiles ou DevOps.

Selon un récent sondage ce type de développement concerne entre 10% et 100% des développements des entreprises aujourd’hui. Ce simple fait démontre que le rôle du RSSI n’est pas d’interdire ce type de méthode au prétexte qu’elles seraient moins sûres mais au contraire de s’impliquer fortement dans les équipes de développement Agile.

La sensibilisation des équipes de développement doit être réalisée sans que cela ne soit pris comme une contrainte mais comme une valeur ajoutée du développement. Lorsque les ressources SSI le permettent il peut être judicieux de déléguer une ressource aux équipes d’innovation qui participera aux sprints de la méthode Agile et de privilégier des méthodes intégrant la sécurité dans le cycle comme DevSecOps.

Une bonne solution pour vérifier la qualité du code développé ainsi que de favoriser les bonnes pratiques, au-delà des classiques dispositifs d’audit de code, est d’utiliser en parallèle un programme de Bug Bounty qui permet de vérifier fréquemment les codes et la sécurité embarquée. Le constat rapide des potentielles erreurs joue le rôle de formation aux bonnes pratiques de développement. Il est important de capitaliser sur les bonnes pratiques et d’en faire des « kit de sécurité » à la disposition des développeurs.

Dans les sociétés pratiquant le 100% Agile il est essentiel d’impliquer les Business Owners dans la démarche car ils seront au bout du compte les gagnants en termes de qualité et de sécurité du code développé. Enfin, il est également important de bien définir dans les User Stories ce que chacun comprend par « Definition of Done (DoD) » et « Definition of Ready (DoR) » entre le client final et l’équipe de développement.

#TousSecNum #CyberSecMonth

Quelques conseils utiles pour le RSSI :

• Sensibiliser les équipes de développement sur le bienfondé du « Security By Design» ;
• S’impliquer dans la démarche de développement Agile et bien comprendre le cycle de développement, parler la « langue» du développeur Agile ; ;
• Changer d’attitude en devenant « Problem Solver» plutôt que censeur ;
• Capitaliser sur des outils de sécurité ;
• Motiver les équipes en créant un « Security Champion» au sein de l’équipe de développement qui se fera le relais opérationnel du RSSI.

Liens utiles :

• ANSSI : Intégrer la sécurité numérique dans une démarche Agile
• Devsecops reference architecture : https://waterplacid.files.wordpress.com/2018/04/devsecops-reference-architectures-2018.pdf
• Sans Institute : Security Road Map for Secure DevOps Toolchain