Les vulnérabilités logicielles font partie des risques les plus élevés en cyber sécurité. Le référentiel BSIMM – Buiding Security in Maturity Model est un outil intéressant pour comparer ses activités de sécurisation du cycle de développement avec les bonnes pratiques du domaine. Une étude annuelle, mise à jour depuis 2008 est menée auprès d’une centaine de grands groupes nord-américains. Cette enquête est suffisamment précise pour quantifier les activités. Le Secure SDLC fait partie du domaine 8 de la certification CISSP. Il est aussi abordé dans les certifications de sécurité Cloud. Cela rejoint aussi les bonnes pratiques C-SCRM en termes de sécurité de la sous-traitance et normes ISO 27034 sur la sécurisation des applications. D'autres référentiels comme SAMM, SAFEcode et SSDF sont régulièrement utilisés.

Modèle de maturité

Le modèle de maturité BSIMM comprend trois niveaux qui mesurent la fréquence à laquelle les activités de sécurité sont constatées parmi les entreprises faisant partie de l’étude annuelle :

• Niveau 1 : activités dont la pratique est très fréquente.
• Niveau 2 : activités dont la pratique est relativement fréquente.
• Niveau 3 : activités dont la pratique est peu fréquente ou nouvelle.

Les principales tendances sont les suivantes :

• Prise en compte des environnement DevOps et Cloud. Par exemple, la sécurisation des opérations d’orchestration des containers.
• Amélioration de la gouvernance. Par exemple, l’automatisation des tests de sécurité.
• Approche qualité de la sécurité des développements. Par exemple, la spécialisation sécurité des ingénieurs chez les éditeurs, au même titre que la qualité.
• Planification de tests de sécurité à toutes les phases de développement.

Les activités du modèle sont organisées en 12 catégories :stratégies et métriques, conformité, modèles d’attaques, conception, standards et exigences, architecture, revue de code, tests de sécurité, tests d’intrusion, environnement logiciel, gestion des configurations et des vulnérabilités.

Exemple d’activités

La pratique "modèles d’attaques" comprend les activités suivantes, classées des plus au moins fréquemment rencontrées :

• Création d’un schéma de classification des données.
• Identification de profils d’attaquants. On retrouve ces notions dans l’évaluation de la menace des méthodes d’analyse des risques comme Ebios Risk Manager par exemple.
• Collecte des informations sur les techniques d’attaques, par exemple avec les TTP du CTI.
• Construction de modèles, en adaptant par exemple celui du MITRE.
• Mise à jour d’une liste d’attack stories pouvant être utilisées dans les projets AGILE.
• Mise en place d’un groupe de chercheurs, à l’instar de Project Zero de Google.
• Développement d’outils pour détecter les nouvelles attaques.
• Supervision automatique de la création des éléments d’infrastructures : containers,, API, environnements Cloud, micro-services….

Autre exemple, les activités de la catégorie "gestion des configurations et des vulnérabilités" :

• Interface avec le processus de réponse aux incidents.
• Interface avec les outils de sécurité opérationnelle.
• Mise en œuvre d’un processus de réactions d’urgence en cas de découverte de vulnérabilités critiques dans le code.
• Simulation d’une crise liée à un problème de sécurité dans le code.
• Exploitation d’un programme de Bug Bounty.
• Automatiser les vérifications du niveau de la sécurité opérationnelle.

  Pour en savoir plus sur les 20 meilleures formations sur la sécurité des systèmes d’information, téléchargez gratuitement notre livre blanc ci-dessous :