ProSE - Serre 4.0

Responsable Cybersécurité

Rédaction de l'analyse EBIOS RM et de la CDS. Sécurisation de la communication entre la carte embarquée et l'application Android via TLS 1.3, en appliquant les recommandations de l'ANSSI, la norme IEC 62443 et les bonnes pratiques SEI CERT.

Responsable Conception

Pilotage de l'équipe de conception : je m'assure de la cohérence entre la conception et la spécification, et je relis le dossier de conception en profondeur avant livraison.

Développeur Android

Sur GMob, je prends en charge la partie réseau (communication avec la carte embarquée) et la gestion des profils utilisateurs.

Analyse de risques EBIOS RM

Pilotage et rédaction de l'analyse de risques complète du système GSol selon les cinq ateliers de la méthode EBIOS Risk Manager de l'ANSSI. Atelier 1 - cadrage du périmètre et formalisation du socle de sécurité (TLS 1.3, contrôle d'accès par rôles et moindre privilège, développement sécurisé IEC 62443-4-1), puis identification de 14 valeurs métier - services et données - et de leurs événements redoutés, cotés en gravité selon les critères Disponibilité / Intégrité / Confidentialité. Atelier 2 - caractérisation de quatre sources de risque (hacker, administrateur, défaillance technique, fournisseur logiciel) et de leurs objectifs visés, dont je n'ai retenu que les couples les plus pertinents pour la suite. Ateliers 3 et 4 - cartographie de menace de l'écosystème, puis construction des scénarios stratégiques et opérationnels via la chaîne « Connaître / Rentrer / Trouver / Exploiter », modélisant des chemins d'attaque réalistes, du phishing et de la compromission du mécanisme de mise à jour jusqu'à l'altération des commandes des actionneurs. Atelier 5 - évaluation du risque résiduel (matrices gravité × vraisemblance avant / après mesures) et plan de traitement détaillé associant à chaque mesure un responsable, un coût / complexité et une échéance.

Cible de sécurité (CDS)

Rédaction de la Cible de Sécurité du système GSol, dans le format d'une cible de sécurité ANSSI (type CSPN) : identification du produit, environnement technique, biens sensibles à protéger et menaces couvertes. Le cœur du document spécifie sept fonctions de sécurité - hachage des identifiants, authentification forte et multifacteur, contrôle d'accès par rôles, protection des communications par TLS, signature des mises à jour et journalisation des événements - chacune répondant aux menaces identifiées lors de l'analyse EBIOS RM.

Dossier de conception

En tant que leader du dossier de conception générale de GSol (incrément 2), pilotage de la rédaction collective et validation du document pour l'audit, en conformité avec la norme IEEE 1016 et la notation UML 2.5.1. À partir du dossier de spécification, l'équipe a défini l'architecture candidate puis logique du système réparti entre l'application Android GMob et le système embarqué GOS sur Raspberry Pi, formalisée par un diagramme de communication, une dizaine de diagrammes de séquence et un diagramme de classes détaillant une quinzaine de composants aux responsabilités distinctes (objets actifs, entités, interface). J'ai personnellement pris en charge le diagramme de classes, le modèle de données (types et énumérations) ainsi qu'une partie des machines à état UML décrivant le comportement des composants. La conception met notamment en œuvre une interface ISensor implémentée par les quatre types de capteurs (polymorphisme) et une séparation nette des responsabilités, des objets de persistance jusqu'à la couche de présentation.

Communication réseau côté Java

En tant que développeur Android, j'ai conçu et mis en place toute la couche de communication réseau de l'application : c'est elle qui permet à GMob et à GOS de dialoguer en continu, dans les deux sens. Les messages échangés sont traduits dans un format compact et universel (Protocol Buffers), afin que l'application et la serre - écrites dans deux langages différents - se comprennent sans ambiguïté. J'ai organisé cette communication autour de rôles aux responsabilités bien séparées : une brique gère uniquement le lien réseau (ouvrir, lire et écrire les données), une autre regroupe ces données en messages complets, un lecteur tourne en permanence pour réceptionner ce qui arrive, un aiguilleur oriente chaque message vers le bon destinataire, et des intermédiaires - les proxys - prennent en charge chacun un grand type d'action de l'application, en envoyant les demandes et en traitant les réponses. Cette séparation claire, où chaque brique ignore le fonctionnement interne des autres, rend l'ensemble simple à faire évoluer et à tester - et c'est précisément ce qui a permis, par la suite, d'ajouter le chiffrement TLS sans rien changer au reste.

Implémentation de TLS 1.3

Sécurisation des échanges entre l'application et la serre, pour empêcher qu'un tiers puisse lire ou modifier les données qui circulent. Ce travail a été mené en binôme avec Martin Le Gall sous la forme d'une exploration : une démarche de veille technique où l'on étudie une technologie nouvelle pour l'équipe, on la teste, puis on la documente précisément pour que n'importe quel développeur puisse ensuite l'installer et la réutiliser. Martin a traité le côté GOS et moi le côté GMob. Nous avons rédigé ensemble un document de référence expliquant le protocole TLS, justifiant nos choix techniques (version, algorithme de chiffrement, certificat) et détaillant les étapes pour le reproduire. Concrètement, l'application reconnaît la serre grâce à un certificat de sécurité embarqué et n'établit le dialogue qu'avec elle, sur un canal entièrement chiffré en TLS 1.3. Grâce à l'architecture en couches mise en place auparavant, l'ajout du chiffrement n'a touché qu'un seul composant, tout le reste étant resté inchangé. Enfin, nous avons prouvé l'efficacité de la protection en comparant le trafic réseau avant et après : sans chiffrement, un mot de passe apparaissait lisible en clair ; avec TLS, les mêmes données devenaient totalement illisibles.

Analyseur de robustesse de mots de passe

Analyseur de robustesse de mots de passe développé en Python sur mon temps personnel dans un but pédagogique et d'apprentissage de la cybersécurité. L'outil évalue en temps réel la solidité d'un mot de passe selon plusieurs critères concrets - sa longueur, sa présence dans une liste de mots de passe divulgués (rockyou), la présence de motifs faciles à deviner (suites, répétitions, formats classiques), la variété des caractères et une estimation de sa complexité - puis le classe sur cinq niveaux, de très faible à très fort. Ces critères s'appuient sur des recommandations reconnues du domaine (NIST SP 800-63B, OWASP). Lorsque le projet GMob a nécessité un contrôle de robustesse à la création de compte, j'ai naturellement réutilisé ce travail : porté en Java, il y sert de véritable garde-fou - un compte ne peut être enregistré que si son mot de passe atteint un niveau suffisant.

Voir le projet sur GitHub ↗