Renforcer la sécurité du code au cloud avec le Common Configuration Scoring System
14 décembre 2023
0 minutes de lectureLes systèmes propriétaires de notation de la sévérité représentent souvent une charge pour les équipes AppSec. Chaque nouveau fournisseur vous oblige à évaluer son propre cadre de sévérité et à traduire les niveaux de risque d’un outil à l’autre. Pour alléger cette charge et fournir à nos clients une évaluation claire de la sécurité des configurations tout au long du SDLC, Snyk va standardiser son ensemble de règles de sécurité du code au cloud selon le Common Configuration Scoring System (CCSS) !
Avec cette mise à jour de l’équipe Snyk Security Research, nous poursuivons notre mission : donner aux développeurs et aux équipes de sécurité les moyens d’évaluer, de hiérarchiser et de trier les problèmes de sécurité plus efficacement, pour un cycle de développement plus sûr et plus performant.
Les règles et leur sévérité dans la dernière version de Snyk Infrastructure as Code (IaC), IaC+, seront évaluées selon le CCSS. Snyk pourra ainsi fournir à ses clients une notation des risques plus précise pour leur infrastructure as code et leurs configurations cloud, en tenant compte de la sévérité technique (CCSS), des renseignements sur les menaces ainsi que du contexte applicatif et métier.
Que signifie la sévérité ?
Les cadres de référence du secteur, comme le Common Vulnerability Scoring System (CVSS) et le Common Configuration Scoring System (CCSS), fournissent une méthodologie précieuse pour évaluer les vulnérabilités et un langage commun à tous. Les fournisseurs n’ont donc pas à inventer leur propre cadre, et les utilisateurs peuvent comparer directement les solutions sans avoir à en traduire les résultats.
En bref, ces cadres définissent plusieurs métriques et un ensemble de formules qui convertissent leurs valeurs en une note de 0 à 10 et en un niveau de sévérité : faible, modéré, élevé ou critique.
Qu’est-ce que le Common Configuration Scoring System ?
Le Common Configuration Scoring System (CCSS) a été créé par le National Institute of Standards and Technology (NIST). Dérivé du CVSS, il a été adapté pour traiter les problèmes de configuration de sécurité logicielle. Comme les mauvaises configurations IaC sont essentiellement des problèmes de configuration de sécurité, nous pouvons leur appliquer le CCSS.
La standardisation avec le CCSS répond à plusieurs des problèmes évoqués précédemment. Elle s’appuie sur une terminologie, des métriques et des formules familières, fondées sur le CVSS, pour attribuer des vecteurs aux mauvaises configurations IaC et ainsi déterminer leur note et leur sévérité.
Snyk peut ainsi remplacer son processus précédent d’attribution de sévérité aux mauvaises configurations IaC. L’adoption de la norme CCSS nous permet également de gagner en transparence : nous affichons le vecteur, la note et la sévérité sans nécessiter un long apprentissage, comme nous le faisons déjà pour les vulnérabilités CVSS.
Le vecteur CCSS du problème ci-dessus est `AV:L/AC:H/Au:M/C:P/I:C/A:N/PL:U/EM:A`. Il donne une note de base de `8.3` et une sévérité `High`. Les six premières métriques figurent dans le graphique ci-dessus, mais pas les deux dernières, `PL` et `EM`, qui correspondent respectivement à `Privilege Level` et `Exploitation Method`. Ces deux métriques ne modifient pas la note de base, mais elles jouent néanmoins un rôle important.
`Privilege Level` peut prendre les valeurs `User`, `Application`, `Root` ou `Not Defined`. Il indique le niveau d’accès non autorisé qu’un attaquant pourrait obtenir. Dans le vecteur et la note de base, `PL` fournit des informations supplémentaires aux utilisateurs et sert au calcul de certaines métriques environnementales.
`Exploitation Method` est plus intéressant, car la valeur de plusieurs métriques de base dépend de celle de la métrique `EM`. Cette dernière peut être `Active` ou `Passive`. Les mauvaises configurations `Active` exposent une vulnérabilité exploitable par un attaquant, par exemple en autorisant la lecture publique de compartiments AWS S3 ou en exposant une base de données protégée par un mot de passe root par défaut. Les mauvaises configurations `Passive` empêchent certaines actions autorisées ou compliquent la tâche des défenseurs. Citons, par exemple, la désactivation de la journalisation des API ou la conservation des sauvegardes d’une base de données pendant une durée insuffisante. Les mauvaises configurations `Passive` relèvent généralement d’une erreur ou d’une violation de politique qui se corrige rapidement, tandis que les mauvaises configurations `Active` peuvent être plus complexes et nécessiter davantage de planification et d’analyse.
Comment Snyk a-t-il mis en œuvre le CCSS ?
Snyk dispose d’un vaste ensemble de règles de sécurité pour vérifier les configurations IaC et cloud, dont la sévérité était attribuée selon le processus précédent. Ajouter manuellement des vecteurs CCSS, calculer les notes et en déduire de nouveaux niveaux de sévérité aurait été fastidieux. La création de scripts aurait pu aider, mais ceux-ci ne permettent pas de prendre des décisions. Heureusement, il existe une meilleure solution !
En intégrant l’IA au processus de mise en œuvre, nous avons simplifié l’adaptation de notre ensemble de règles existant aux normes CCSS. Guidée par des prompts et enrichie par notre expertise unique, l’IA nous aide à déterminer la sévérité de chaque mauvaise configuration avec cohérence et précision. Cette avancée améliore la transparence et la fiabilité de nos évaluations de sécurité pour les utilisateurs, tout en réaffirmant l’engagement de Snyk à faire figure de pionnier dans la sécurité centrée sur les développeurs.
Forts de notre expérience préalable en matière d’IA, nous avons condensé la spécification CCSS dans un prompt, accompagné de recommandations supplémentaires fondées sur nos recherches. Après analyse des résultats, voici comment se répartissent les niveaux de sévérité :
Et voici la nouvelle répartition :
Les graphiques ci-dessus montrent que nos anciennes évaluations de sévérité chez Snyk étaient souvent bien plus prudentes que celles du CCSS.
La standardisation de notre système de sévérité selon le CCSS nous donne non seulement un processus reproductible pour déterminer la sévérité des règles, mais préserve aussi de précieuses données contextuelles pour approfondir les analyses, comme le score de risque de Snyk. De plus, l’analyse de la distribution des notes de base dans notre ensemble de données révèle une courbe en cloche. Ce résultat correspond à la distribution statistique attendue pour des notes comprises entre 0 et 10 et confirme la fiabilité de la méthode CCSS, qui produit des évaluations de sévérité équilibrées et prévisibles grâce à l’IA.
Quelle est la prochaine étape pour Snyk IaC ?
Suivez les actualités de nos équipes de recherche en sécurité et le déploiement des niveaux de sévérité CCSS sur updates.snyk.io !
Vous souhaitez en savoir plus sur le Common Vulnerability Scoring System (CVSS), utilisé depuis près de deux décennies ? Nous en avons parlé à de nombreuses reprises.
Vous souhaitez en savoir plus sur l’utilisation de l’IA comme outil de développement pour enrichir nos recherches en sécurité ? Nous en avons parlé ici, notamment avec quelques bonnes pratiques.
