Gérer les 10 principaux risques de l'OWASP

Tous les accès sont autorisés par notre système dorsal sur la base des données nécessaires, notamment l'identité de l'appelant, le point d'accès appelé et les paramètres de la demande, afin d'empêcher l'escalade verticale et horizontale des privilèges. Les solutions de contrôle d'accès sont réutilisées dans la mesure du possible. Les appels API liés à l'authentification sont limités en taux afin de réduire le risque de DoS et de collecte automatisée de données.

Toute connexion entre des clients web ou des appareils récents et nos serveurs prend toujours en charge le protocole TLS. Cela inclut les connexions entre les navigateurs des clients et nos serveurs web, mais aussi les connexions entre les appareils et nos services. Les protocoles en texte brut ne sont pas utilisés pour les communications entre appareils qui transmettent des données sensibles, à moins qu'il ne s'agisse d'une exigence spécifique du client pour la communication entre appareils.

Les algorithmes cryptographiques et la puissance des clés sont régulièrement revus et mis à jour si nécessaire.

Les données au repos dans nos bases de données SQL sont stockées sur des volumes cryptés.

En tant que première ligne de défense contre les vulnérabilités de type injection, nos applications web mettent en œuvre la validation des entrées. Le type et le format des données saisies par l'utilisateur sont validés dans la mesure du possible.

Les cadres modernes fournissent également un encodage approprié pour empêcher les injections lors de la création de certains objets, y compris les documents XML, ce qui réduit le risque de telles vulnérabilités.

Le risque d'injection SQL est encore réduit de manière significative par l'utilisation correcte d'un ORM.

Le risque d'injection de commandes du système d'exploitation est également fortement réduit par la pile technologique sous-jacente basée sur Java, où les commandes du système d'exploitation ne sont jamais exécutées à partir du code.

En ce qui concerne les XSS, nous examinons manuellement notre code et nos environnements de test pour détecter les scripts intersites. Certaines technologies et certains cadres que nous utilisons contribuent à prévenir les XSS en appliquant par défaut un codage approprié.

Nos normes internes de sécurité du codage et nos principes de conception sécurisée servent de liste d'exigences en matière de sécurité et fournissent une liste de règles que l'ensemble du code et de l'architecture doivent respecter. Lorsque nous prenons des décisions sur des améliorations potentielles, nous tenons compte de sources telles que le BSIMM et le SAMM. Notre Conseil de sécurité assure la gouvernance et la supervision de la conception de la sécurité.

Nous visons à mettre en œuvre le principe du moindre privilège à tous les niveaux de notre pile technologique. La surface d'attaque est également réduite en n'installant que les composants nécessaires. La configuration des serveurs est gérée par des solutions automatisées afin de garantir la conformité avec les politiques internes. Les configurations au niveau des applications sont également gérées automatiquement et vérifiées par l'examen du code de sécurité et l'analyse statique.

Pour le traitement XML, le traitement DTD en ligne est désactivé dans la mesure du possible, ou des mesures d'atténuation appropriées sont appliquées lorsque cela est nécessaire.

Nous examinons les composants de tiers et leurs vulnérabilités. Les composants présentant des vulnérabilités sont évalués et, si la vulnérabilité affecte nos services, une mise à jour ou un correctif est programmé en fonction du risque. Dans le cas des composants open source, cette démarche est également appuyée par les notifications GitHub des composants vulnérables. En outre, nous effectuons des analyses régulières du réseau pour trouver les services vulnérables dans nos environnements.

Nos applications web exigent des mots de passe forts conformément aux recommandations du NIST (NIST 800-63-3).

Les comptes sont verrouillés pour des périodes de temps exponentiellement croissantes après un certain nombre de tentatives de connexion infructueuses. Les tentatives de connexion réussies et échouées sont enregistrées. La récupération du mot de passe se fait par courrier électronique, où seuls des jetons sont envoyés. Les mots de passe ne sont jamais envoyés par courrier électronique. Les mots de passe de la base de données sont hachés à l'aide d'une fonction de dérivation de clé appropriée (et non d'un simple hachage cryptographique), en utilisant des implémentations standard et bien connues. Cela permet d'éviter les attaques par force brute, même sur une liste connue de hachages de mots de passe.

Nos services web sont mis à jour par l'intermédiaire d'un pipeline CI fiable et révisé. Les vulnérabilités des modules tiers sont vérifiées par une automatisation partiellement fournie par GitHub. Les appareils utilisent des mises à jour de microprogrammes signées et ne chargent pas d'images non signées ou non fiables. Les microprogrammes ne peuvent être signés qu'au moyen d'un processus rigoureux et soigneusement conçu qui protège de manière adéquate les clés de signature.

Les événements vérifiables sont enregistrés et les journaux sont collectés en temps réel dans un référentiel central. Les pistes d'audit sont disponibles. Nous avons mis en place une surveillance des applications pour détecter les anomalies. La journalisation n'inclut jamais de secrets et est conforme au GDPR.

Les développeurs sont conscients de l'existence du SSRF, les révisions de code et l'analyse statique contribuent à prévenir de tels problèmes. Les données d'entrée de l'utilisateur sont nettoyées si nécessaire afin d'atténuer le SSRF. Nos tests de pénétration visent également à détecter des problèmes similaires.