Sécurité
Blueteam est d'abord une société de sécurité
C'est ce qui change la façon dont nous construisons vos outils, autant que ce que nous pouvons faire autour.
D'où vient cette compétence
- Depuis 2008
- Missions de sécurité et d'infrastructure pour des PME, des start-up et des fondations.
- Depuis 2014
- Responsable de la sécurité des systèmes d'information de l'ENS de Lyon.
- 2021
- Certification ISO 27001 Lead Implementer.
- 2023
- Investigation numérique et forensic (HS2).
- Depuis 2024
- RSSI adjoint de l'ENTPE, école d'ingénieurs et laboratoire de recherche.
Protéger des laboratoires de recherche et des établissements ouverts sur l'extérieur, c'est faire de la sécurité avec des moyens contraints et des utilisateurs qui ne peuvent pas être bridés. C'est exactement la situation d'une PME.
Où se situe le risque aujourd'hui
Sur les incidents que nous traitons, l'entrée se fait rarement par une faille du code métier. Elle se fait par un mot de passe réutilisé, une interface d'administration restée ouverte sur Internet, un composant qui n'a pas été mis à jour depuis deux ans, un compte de service sans double facteur. Le code de votre application est une surface parmi d'autres, et rarement la plus exposée.
La gravité se joue ensuite sur l'état des sauvegardes : leur fréquence, leur emplacement, et la date du dernier essai de restauration.
Accès et identités
Comptes partagés entre plusieurs personnes, départs jamais traités, double facteur absent sur les accès distants et sur la messagerie.
Ce qui est exposé sans le savoir
Une interface d'administration, un partage de fichiers, un accès distant au serveur, publiés un jour pour dépanner et jamais refermés.
Composants non corrigés
Bibliothèques applicatives, systèmes et équipements réseau qui ne reçoivent plus de correctifs, souvent parce que personne n'en a la charge.
Sauvegardes à portée de main
Présentes, mais accessibles depuis le même compte que les données : un rançongiciel qui prend le serveur chiffre les deux dans la même heure.
Comment nous vérifions ce que nous livrons
Deux analyses tournent sur chaque application que nous livrons.
Analyse statique du code
Elle lit le code source sans l'exécuter, et tourne à chaque modification en une trentaine de secondes. Elle s'appuie sur des référentiels de règles publics, complétés par des règles écrites pour votre application au fur et à mesure que des défauts y sont rencontrés. Elle recherche également les mots de passe et les clés laissés en clair dans le code.
Analyse dynamique de l'application
Elle attaque l'application en fonctionnement, sans accès au code. Une passe rapide à chaque livraison vérifie les en-têtes de sécurité, les cookies et la protection contre les requêtes forgées. Une passe complète, avant chaque mise en production, recherche les injections, les scripts injectés et les traversées de répertoire. Elle détecte des défauts de configuration que l'analyse statique ne peut pas voir.
Sur une instance dédiée
L'analyse dynamique ne tourne jamais sur votre production. Elle monte une instance neuve, de même configuration, avec une base de données fictive, détruite après l'analyse.
Les écarts seulement
Chaque constat examiné est consigné avec sa justification. L'analyse suivante ne présente que les constats nouveaux.
Blocage de la livraison
Quand l'analyse échoue, la mise en ligne est interrompue tant que le constat n'est pas traité.
Le détail des contrôles
Les quatre premiers tournent sur le code et sur l'application ; les deux derniers vérifient ce qu'un visiteur voit réellement.
| Contrôle | Ce qu'il cherche | Cadence |
|---|---|---|
| Analyse statique | Semgrep, avec les référentiels publics p/python, p/security-audit, p/command-injection et p/secrets, complétés par des règles écrites pour votre code : requête SQL assemblée par concaténation, entrée de requête affichée sans échappement, redirection construite depuis l'URL, exécution dynamique de code, chemin de fichier issu de la requête, cookie de session sans HttpOnly. | chaque modification |
| Recherche de secrets | Gitleaks : clés d'API, mots de passe et jetons laissés en clair dans le code ou dans les fichiers de configuration. | chaque modification |
| Analyse dynamique, passe passive | OWASP ZAP, sans accès au code : en-têtes de sécurité, attributs des cookies, politique de sécurité du contenu, absence de jeton anti-CSRF dans les formulaires, pages authentifiées laissées en cache. | chaque livraison |
| Analyse dynamique, passe active | OWASP ZAP attaque l'application en fonctionnement : injections SQL, scripts injectés, traversée de répertoire, paramètres manipulables. | avant production |
| Contrôle d'accès | Un harnais écrit pour votre application : chaque route interrogée sans session, cookie de session forgé de plusieurs façons, écriture tentée sans jeton anti-CSRF, méthodes HTTP inattendues, identifiants hors bornes, et une charge injectée relue sur toutes les pages qui la réaffichent. | chaque modification |
| Contrôle d'exposition | Vu d'Internet : redirection de HTTP vers HTTPS, versions de TLS acceptées, validité et chaîne du certificat, bannières de version, listing de répertoire, code source ou base de données servis par erreur, ports ouverts. | chaque déploiement |
Les deux applications de démonstration publiées sur demo.blueteam.pro passent par cette même chaîne.
Ce que nous durcissons
Dans l'application
Une politique de sécurité du contenu qui interdit les scripts en ligne et le chargement de ressources extérieures. Un jeton anti-CSRF sur chaque écriture, formulaire de connexion compris. Un cookie de session HttpOnly, SameSite et Secure, limité au chemin de l'application et révoqué côté serveur à la déconnexion. Des requêtes SQL toujours paramétrées, des entrées numériques bornées, un échappement systématique à l'affichage. Les en-têtes d'isolement du contexte de navigation, et des pages authentifiées qu'aucun cache ne conserve. Un journal d'audit qui garde qui a modifié quoi, quand et depuis quel poste.
Sur le serveur
Tout le trafic en HTTP redirigé vers HTTPS, avec HSTS, et seules les versions 1.2 et 1.3 de TLS acceptées. L'application tourne sous un compte dédié sans interpréteur de commandes, isolée par systemd : système de fichiers en lecture seule, répertoire temporaire privé, aucune élévation de privilèges possible, mémoire non exécutable, quota de mémoire et de processus. Elle écoute sur la boucle locale, derrière le serveur web ; la base de données n'est jamais exposée. Ni listing de répertoire, ni version dans les bannières, et les ports qui n'ont rien à faire sur Internet restent fermés.
Ces réglages sont vérifiés par les deux derniers contrôles du tableau ci-dessus, après chaque déploiement.
Dans l'outil que nous livrons
Tests de non-régression
Chaque faille corrigée est couverte par un test qui échoue si le correctif disparaît. Le test est lui-même vérifié : on s'assure qu'il échoue bien sans le correctif.
Test d'intrusion avant la production
Pour toute application publiée sur Internet. Vous recevez le rapport et la liste de ce qui a été corrigé.
Pas de mot de passe de plus
Authentification adossée à votre annuaire existant : Microsoft 365, Google, Nextcloud. Un départ dans l'entreprise ferme l'accès à l'application le jour même.
Journal d'audit et cloisonnement
Qui a modifié quoi, quand, depuis quel poste. Les droits suivent les rôles réels de l'entreprise, pas une hiérarchie théorique.
Sauvegardes testées
Chiffrées et hors site, selon la règle 3-2-1 décrite plus bas, avec une restauration réellement rejouée à intervalle convenu.
Maintien en condition de sécurité
Correctifs appliqués en continu pendant toute la vie de l'application. C'est inclus, ce n'est pas une option à renouveler chaque année.
La sauvegarde, en 3-2-1
C'est la règle que nous appliquons sur ce que nous hébergeons, et celle que nous mettons en place chez nos clients quand elle n'y est pas. Elle tient en trois nombres.
Trois copies des données
Les données en production, plus deux sauvegardes indépendantes l'une de l'autre. Si l'une échoue ou se révèle illisible au moment de la restauration, la seconde reste disponible.
Deux supports de nature différente
Par exemple un disque sur site et un stockage objet chez un hébergeur. Un défaut qui touche un type de support, un modèle de disque ou un hyperviseur n'atteint pas l'autre.
Une copie hors site
Dans un autre datacenter, avec des identifiants distincts de ceux du système sauvegardé. Un incendie, un vol ou un rançongiciel qui prend la main sur le serveur ne l'atteint pas.
Ce que vous perdriez au pire
La fréquence des sauvegardes fixe la quantité de travail perdue en cas de sinistre. Nous la choisissons avec vous, en heures, selon ce que représente une journée de saisie pour votre activité.
Sur le reste de votre système
Indépendamment de tout développement, et pour des entreprises qui n'ont pas de RSSI à temps plein.
Audit et durcissement
Postes de travail, serveurs, cloud. Un état des lieux compréhensible par un dirigeant, et une liste d'actions classées par effet sur le risque.
Authentification
Double facteur, gestionnaire de mots de passe, revue des accès, suppression des comptes oubliés — l'essentiel des intrusions passe par là.
Sauvegardes et continuité
Vérifier ce qui existe, le remettre en 3-2-1 si ce n'est pas le cas, et rejouer une restauration pour connaître le temps de remise en service.
Sensibilisation des équipes
Des sessions courtes, avec des exemples pris dans votre métier plutôt que des rappels généraux.
Questionnaires sécurité
Vos clients grands comptes et vos investisseurs vous en envoient. Nous y répondons avec vous, et nous comblons ce qui doit l'être.
Réponse à incident
Quand c'est déjà arrivé : contenir, comprendre, restaurer, et documenter ce qui s'est passé.
Trente minutes sur un cas réel suffisent
Le plus simple est de vous montrer un outil en fonctionnement. Vous verrez tout de suite si cela correspond à votre situation.