Cyberattaque contre Sony en 2011, contre Game of Thrones en 2017 ou encore contre de nombreux hôpitaux français en 2022… le monde de la cyber est un domaine qui fascine autant qu’il fait peur ! Confrontées à plus de 800 intrusions cyber en 2022, les entreprises consacrent une importance toujours plus forte à la protection de leurs données, celles de leurs collaborateurs ou de leurs clients. Sylvain consultant ingénieur logiciel et scrum master au sein du Groupe Astek à Rennes, nous explique comment il intervient pour la protection des applications des entreprises.
Avant tout, il faut savoir que la cyber n’était pas mon domaine de prédilection, j’ai commencé à l’ICAM Toulouse, une école d’ingénieurs généraliste, puis j’ai poursuivi mes études avec un « master in computer science » en Pologne et mon mémoire d’études y portait sur l’informatique médicale appliquée à la détection de fibroses pulmonaires grâce à la vision par ordinateur. Je suis resté 3 ans de plus dans ce pays pour travailler dans différents domaines de la tech. Ce qui m’attire, c’est plus le challenge d’évoluer dans des domaines assez sensibles. C’est d’ailleurs comme ça que je suis arrivé chez Astek en rentrant en France au début de l’année 2022. Aujourd’hui, cela fait donc un peu plus d’un an que je travaille en tant que développeur sécurité et scrum master sur les applications d’un grand Groupe du secteur des télécoms.
La cybersécurité est un domaine assez complexe. Pour sécuriser une application, il ne suffit pas d’écrire quelques lignes de code et de les déployer sur un serveur. Déjà, il faut vérifier la sécurité de l’application elle-même, des réseaux qu’elle utilise et de nombreux autres facteurs ; en plus, on doit s’assurer qu’aucun des logiciels qui communiquent entre eux ne présentent de faille.
Dans mon quotidien, je travaille pour le développement de certaines applications de sécurité de l’entreprise. Comment ça se passe ? En fait, je participe à deux projets distincts :
- Le premier est une application centralisée de sauvegarde de configurations de système de sécurité (VPN, Pare-feu, Bastion, etc.), quelles que soient leurs marques.
- Le second est une application centralisée pour l’enregistrement de différents équipements de sécurité dans divers systèmes, tels que des asset managers, des bastions, des gestionnaires d’adresse IP, etc.
Ces projets étant voués à la sécurité, il est important de vérifier qu’ils ne contiennent pas d’éventuelles failles en eux-mêmes ou dans leurs dépendances, et de ne pas en introduire lors du développement de nouvelles fonctionnalités ou de la correction de bugs.
Pour mener à bien ces projets, il faut prendre en compte tout le cycle de vie du produit, de sa conception à son utilisation, en passant par l’architecture des systèmes liés au projet, l’architecture logicielle, le développement, le code quality, le ou le refactoring, sans oublier le management de projet.
Une faille de sécurité est d’abord détectée, soit par une équipe externe (une « red team ») qui nous transmet l’information, soit par nos outils automatiques d’analyse de code ou nos scanners de sécurité d’application. Mon équipe se charge alors de vérifier la conformité de la partie de l’application concernée afin de proposer des solutions de correction. Pour cela, nous cherchons les détails de la faille et réalisons une série de tests, automatisés ou plus complexes. Une fois l’ensemble des problèmes détectés, nous cherchons à les résoudre en intervenant directement sur le code et l’infrastructure de l’application. Nous en profitons pour réaliser du refactoring en retirant tout le code qui n’est pas nécessaire et en nettoyant les code smells. Une fois toutes les corrections apportées, nous refaisons une série de tests pour vérifier qu’il ne reste pas de faille visible. Lorsque nous sommes surs que notre travail est abouti et que les modifications sont prêtes, nous faisons d’abord une « merge request » du code imposant une revue par un autre membre de l’équipe. Une fois la validité du code de remplacement confirmée, nous le mergeons sur la branche principale. Ensuite cela passe à une autre équipe qui assure les tests et, si les résultats sont concluants, nous déployons en production.
La finalité de l’application étant la sécurité, il faut, comme pour toute autre application, tester son bon fonctionnement. Par exemple, nous devons assurer une mise à jour pertinente de l’application de sauvegarde des équipements de sécurité et cela passe, entre autres, par sa traçabilité. Chaque sauvegarde et les modifications qui y sont associées doivent être répertoriées afin de retrouver facilement la faille si un incident est déclaré.
Pour concilier au mieux les deux projets, rendre des livrables complets et dans les meilleurs délais, travailler en mode agile est devenu indispensable. Avec la méthode Scrum, chacun de nos sprints dure 3 semaines. Le Scrum a de nombreuses utilités dont le daily pour vérifier que nous arrivons à avancer tous en équipe sur nos différentes tâches dans les temps et sans blocage. Le sprint planning et la rétrospective sont également importants pour revoir l’ancien sprint et planifier le suivant.
Forcément comme dans tous les domaines, il y a des bonnes pratiques à suivre ; et c’est encore plus vrai quand on parle de sécurité ! Dans un premier temps, nous ne travaillons jamais sur l’internet public mais nous accédons toujours à nos applications à travers un VPN. Ensuite, on suit le principe du 0 trust. De quoi s’agit-il ? Quand on code ou que l’on fait nos tests, on part du principe qu’on ne fait pas confiance aux utilisateurs finaux pour bien utiliser l’application et qu’il faut donc adopter une protection totale. Nous faisons de la veille technologique en suivant, entre autres, le guide des bonnes pratiques de l’Open Web Application Security Project. Son rapport des préoccupations en matière de sécurité web « OWASP Top 10 » liste les 10 risques de sécurité les plus critiques et les précautions à adopter au quotidien. Nous adaptons nos tests automatisés à ce top 10 tout en maintenant les tests existants sur d’autre failles éventuelles. Nous travaillons aussi beaucoup avec SQL ou NoSQL pour nous assurer que les bases de données sont bien protégées et que les utilisateurs ne peuvent pas créer leurs propres requêtes impactant les données sauvegardées sur les serveurs.
Nous utilisons également des outils comme SonarQube, un linter de code qui détecte des failles de sécurité dans le code ou dans la configuration (e.g. CORS, Injection SQL, etc…), comme Owasp ZAP, qui réalise des tests de pénétration automatisés ou encore comme Owasp Dependency Check, qui inventorie et vérifie les dépendances.
La cybersécurité est un domaine très challengeant parce qu’on sent l’importance et l’impact direct de notre travail au quotidien ; et puisque le challenge m’est indispensable, forcément, j’aime ce domaine. Mon goût pour le challenge m’a aussi poussé à être référent de site interne (RSI) et à être responsable de la cohésion des collaborateurs Astek travaillant dans les locaux du client. J’organise des groupes de discussion, des petits déjeuners et des afterworks. Je m’assure que les collaborateurs ont bien toutes les informations transmises par le Groupe et qu’ils sont satisfaits au sein d’Astek. En plus du défi que cela comporte, ça me permet de mieux connaître les personnes avec qui je travaille et de confirmer mon engagement pour le Groupe Astek.