TL;DR
En mai 2024, cside a été lancé en tant que première solution de sécurité côté client d'intégrer l'IA dans son produit.
Nous utilisons des modèles open source auto-hébergés sur notre propre infrastructure pour analyser JavaScript à la recherche d'intentions malveillantes. Expliquez le comportement des scripts dans un langage simple, suivez les modifications au fil du temps et automatisez les examens de conformité des scripts PCI DSS 4.0.1.
Contrairement aux solutions qui exploitent des API d'IA tierces, notre architecture empêche la fuite de données et protège la confidentialité des utilisateurs finaux en utilisant des LLM open source auto-hébergés. Pour les organisations soumises à des restrictions en matière d'IA, ces fonctionnalités peuvent être désactivées. L'IA est une superposition et non une exigence, mais elle s'est avérée incroyablement précieuse pour les équipes GRC et de sécurité.
La sécurité côté client à l’ère de l’IA
Lorsque nous avons lancé cside en mai 2024, nous voulions détecter les attaques que d'autres n'avaient pas. Nous avons donc pris une décision qui nous distingue de tous les autres acteurs du secteur de la sécurité côté client : nous avons intégré l’IA au cœur de notre produit dès le premier jour.
À l’époque, nous étions le seul fournisseur de solutions à utiliser les LLM pour assurer la sécurité JavaScript côté client. Plus tard, le reste du marché a suivi notre exemple, mais la manière dont vous implémentez l’IA est tout aussi importante que les fonctionnalités qu’elle fournit.
Pourquoi l'IA est importante pour la sécurité JavaScript
JavaScript est particulièrement difficile à analyser. Les fournisseurs de solutions SAST utilisent également des LLM pour analyser le code. Mais les scripts côté client changent constamment, sont volontairement obscurcis et peuvent se comporter différemment en fonction de qui les consulte, de l'endroit où ils se trouvent ou de l'heure qu'il est.
La correspondance de modèles traditionnelle s'effondre lorsque les attaquants randomisent leur code ou ciblent des utilisateurs spécifiques.
Contrairement aux systèmes d'exploitation, les navigateurs n'ont pas été conçus pour assurer la sécurité. C'est pourquoi cside propose plusieurs approches pour combler les lacunes :
- Méthode Script (la plus simple) : nous vérifions le comportement des scripts dans le navigateur et récupérons les scripts de notre côté, puis nous vérifions qu'il s'agit bien du même script. Nous ne nous plaçons pas dans le chemin d'un script sauf si vous nous le demandez explicitement. Facile à implémenter, sans impact sur les performances, et vous pouvez toujours stopper des actions de script ou bloquer par URL, hash ou domaine.
- Méthode Scan (la plus rapide) : si vous ne pouvez pas ajouter de script à votre site, cside l'analyse en s'appuyant sur des renseignements de menaces collectés sur des milliers d'autres sites web cumulant des milliards de visites. Rapide à mettre en place et utile lorsque l'installation d'un script n'est pas possible.
La combinaison de ces modes nous rapproche le plus d’une couverture complète techniquement possible aujourd’hui.
Les LLM sont vraiment efficaces pour contextualiser JavaScript même lorsqu'il a été mutilé au point de devenir méconnaissable. Un LLM peut examiner le code obscurci, comprendre son intention et signaler un comportement que l'analyse statique manquerait complètement. Cette fonctionnalité est incroyablement précieuse pour la sécurité JavaScript. Mais seulement si cela est mis en œuvre de manière responsable.
Architecture d'IA responsable : pourquoi nous nous auto-hébergons
cside exécute des LLM open source sur notre propre infrastructure cloud. Nous maintenons un contrôle total sur les données qui circulent dans nos modèles.
Souvent, lorsque les entreprises proposent des fonctionnalités compatibles avec l’IA, elles utilisent par défaut les API de sociétés d’IA bien connues. Bien que ces entreprises disposent de données de fonctionnalités utilisées dans la formation sans consentement, les données sont fournies à un tiers. Dans un monde idéal, les données ne quittent jamais votre zone de contrôle.
En exécutant nous-mêmes des modèles open source, il n'y a aucun risque de fuite du contenu des scripts vers des fournisseurs externes. Il n'y a aucune chance que les données client apparaissent dans un ensemble de formation.
Lorsque vous envoyez du JavaScript à une API tierce, vous faites confiance aux politiques de traitement des données de ce fournisseur, qui changent activement au fil du temps.
cside comprend les exigences de sécurité et ce qu'il faut pour protéger vos données. Vous pouvez vérifier vous-même notre posture de sécurité sur notre Centre de confiance, où nous publions notre documentation SOC 2 Type II, pen-tests et PCI DSS AOC.
Comment cside utilise l'IA : 4 applications principales
Voici où l'IA s'exécute réellement dans notre produit.
1. Analyse des scripts à la recherche d'intentions malveillantes
Chaque script chargé sur votre site est analysé dans sa forme originale et après désobfuscation. Le LLM recherche des modèles qui indiquent des comportements malveillants :
- Vol de jetons de session
- Interception et exfiltration de données non autorisées
- Récolte des informations d'identification
- Falsification des formulaires de paiement
Cela s’applique tout autant aux scripts épurés qu’aux scripts plus alarmants. Que ce soit dans le bloc JavaScript principal ou dans une petite sous-requête.
L'IA capture les deux. Il comprend le contexte d'une manière que les détections basées sur les expressions régulières ne peuvent tout simplement pas comprendre. Et contrairement à scanners, CSP ou produits basés sur des agents, nous analysons la charge utile réelle que vos utilisateurs reçoivent, nous savons que c'est exactement ce que l'utilisateur a reçu. Nous ne nous contentons pas de vérifier les informations provenant des menaces ou d'attendre que les pièges côté client se déclenchent, même si nous utilisons bien sûr également ces méthodes comme couches dans notre moteur de détection.
La couche IA de notre moteur de détection n’est qu’une couche parmi tant d’autres, mais l’IA peut être très efficace pour détecter les comportements malveillants cachés.
2. Raisonnement commercial du script
- Ce widget de chat devrait-il avoir accès aux données du formulaire ?
- Pourquoi ce script d'analyse se trouve-t-il sur votre page de paiement ?
- Cet outil marketing doit-il être exécuté dans le cadre du processus de paiement ?
Nous fournissons une raison commerciale générée par LLM, qui constitue une exigence de conformité pour certains frameworks.
Gain d’heures d’enquête aux équipes. Au lieu d'examiner chaque modification de hachage de script ou d'essayer de trouver qui l'a ajouté, vous obtenez une explication en langage simple de ce que fait chaque script.
3. Expliquer les changements au fil du temps
Les scripts ne restent pas statiques. Beaucoup mettent à jour constamment. La semaine dernière, le script X a effectué des actions liées à l'analyse. Cette semaine, il accède également à localStorage et effectue des requêtes vers un nouveau domaine enregistré pointant vers une adresse IP résidente.
Qu’est-ce qui a changé et est-ce important ?
L'IA de cside génère des explications lisibles par l'homme pour les modifications de script. Vous n'avez pas besoin d'être un chercheur en sécurité pour comprendre ce qui s'est passé entre les changements. La plateforme vous indique exactement ce qui est différent et si cela soulève des inquiétudes.
Ceci est très utile pour les audits de conformité. Lorsqu'un auditeur vous pose des questions sur le comportement du script au cours des six derniers mois, vous disposez d'explications documentées et horodatées prêtes à l'emploi. Notre suivi historique à 100 % signifie que rien n'est perdu.
4. IA pour l'automatisation de la conformité PCI DSS 4.0.1
Les exigences PCI DSS 4.0.1 6.4.3 et 11.6.1 imposent une révision continue des scripts sur les pages de paiement. La plupart des équipes gèrent cela manuellement : charger la page, inspecter les scripts, tout documenter et répéter le processus chaque semaine ou mois.
Avec Bouclier PCI, l'IA gère automatiquement la révision. Chaque changement de script sur les pages de paiement est analysé. Si le changement semble bénin, aucune action n’est requise. S'il montre des signes de comportement malveillant, vous recevez une alerte avec un détail complet de ce qui s'est passé.
Cette approche a été validée par VikingCloud, qui a confirmé que cside répond aux exigences PCI DSS 4.0.1 6.4.3 et 11.6.1 lorsqu'il est déployé correctement. Vous pouvez lire le rapport complet ou téléchargez-le depuis notre Centre de confiance.
Ce n'est pas seulement une question de commodité. C'est la différence entre une réponse réactive aux incidents et une prévention proactive des menaces.
La flexibilité est la réponse
Nous comprenons que toutes les organisations ne sont pas prêtes à adopter l’IA dans l’ensemble de leur pile technologique. Certains ont des politiques internes contre l’utilisation de l’IA. D'autres souhaitent l'évaluer au cas par cas.
C'est pourquoi toutes nos fonctionnalités d'IA peuvent être désactivées. La superposition est là si vous le souhaitez, mais il n'est pas obligatoire d'exécuter cside.
Vous bénéficiez toujours d’une visibilité complète sur la charge utile, d’un blocage en temps réel, d’un suivi historique et de rapports de conformité sans IA.
Que vous utilisiez la Méthode Script ou la Méthode Scan, la plateforme offre une visibilité complète sur les scripts et une conception fail-open. L'IA est une amélioration et pour les équipes qui peuvent l'utiliser, la couche IA rend tout plus rapide et plus précis.
Pourquoi c'est important maintenant
Les attaques côté client sont de plus en plus sophistiquées. Les attaquants savent que le côté serveur et vos dépendances open source statiques sont étroitement surveillés. Ils ont donc ajusté leur surface d'attaque et sont :
- Utilisation de scripts dynamiques côté client qui changent en fonction du contexte utilisateur, évitant ainsi la détection par des analyses statiques.
- Scripts fortement obscurcissants pour éviter l’analyse statique.
- Exploiter l'écart entre ce que permettent les spécifications du navigateur et la façon dont le navigateur est réellement construit.
Les outils de case à cocher ne peuvent pas suivre. Les violations CSP ne vous indiquent pas le contenu d'un script et sont difficiles à gérer. Les robots d'exploration reçoivent des charges utiles propres tandis que les vrais utilisateurs voient les charges utiles malveillantes. La surveillance comportementale ne détecte les attaques qu'une fois qu'elles ont déjà été exécutées et est susceptible de contourner les méthodes.
Les détections basées sur l’IA et une approche combinant les méthodes ont les meilleures chances. Analyse le comportement en temps réel, comprend le code obscurci même lorsque la désobfuscation échoue et signale les anomalies que la correspondance de modèles manquerait.
Modèles auto-hébergés, infrastructure isolée et aucun partage de données avec des tiers. C’est ainsi que vous bénéficiez des avantages de l’IA sans introduire de nouveaux risques ni faire face à des résistances internes.
Prêt à découvrir cside out ? Commencez gratuitement ou réserver une démo pour discuter avec notre équipe.
