object.title
DevSecOps : Approche et généralités

Par

N. C. B. Diop – TheExpert Sécurité des applications chez Squad, DT Cybersécurité

Introduction

Le DevSecOps ( Développement-Sécurité-Opérations) est un tremplin entre le développement, l’automatisation des tests et la sécurité. Il engage chaque acteur du cycle de développement d’un logiciel ou d'une application, le rendant responsable de la sécurité. En terme technique, son application requiert le modèle « Security by design ». Il englobe une large compétence entre l’architecture technique, la recette de sécurité et le développement.

Comme le DevOps, le DevSecOps vise à mettre en place le modèle « Security by design » tout en adoptant l’aspect « sensibilisation et formation ».

Il parait très important de montrer les enjeux et les avantages, d’expliquer l’intégration d’un tel modèle, de donner la vision mise en place avec la méthodologie et la procédure à mettre en œuvre afin d’arriver à un résultat optimal.

Notons que pour chaque environnement, un modèle doit être défini selon leur écosystème.

Enjeux et avantages

Beaucoup d’entreprises n’ont pas encore évalué le niveau de criticité l’absence de sécurité dans leur application. Les enjeux d’un manque de sécurisation aux niveaux des applications sont pourtant critiques.  L’impact financier est significatif :  on estime qu’il est 30 fois moins cher de mettre la sécurité en amont de phase que durant la phase de production.

Une sensibilisation face à ces enjeux est importante pour alerter et faire accepter aux entreprises, à la recherche d’innovation, ce modèle.


Pour une entreprise, les risques concernent également son image ou le vol de données client. La réputation d’une entreprise en ces temps d’attaques, est très importante. Avec l’accroissement des pirates et hackers dans le monde numérique, la prévention reste la meilleure défense face aux cyberattaques.

Lorsque l’application est contrôlée depuis la phase d’étude en termes de sécurité, il est alors 100 fois moins cher d’anticiper et de corriger les vulnérabilités pendant la phase de déploiement.

Les avantages d’une telle mise en place sont divers et variés. Il y’a la confiance des consommateurs, la réputation et la notoriété. Sans oublier la réduction du coût de maintenance liés à des correctifs de sécurités épargnés pour les applications.


Intégration de la sécurité en mode agile

Les tests d’intrusion

Les tests d’intrusion restent la pratique la plus efficace pour minimiser les risques liés aux applications web ou mobile utilisant des services Web. Ils sont effectués par le biais d’outils commerciaux ou gratuits.

Revue de code

Les outils d’analyse statique permettent d’industrialiser la détection de ces vulnérabilités. Les produits comme Checkmarx permettent d’avoir un graphe d’exécution pour la détection de données d’entrées. La série de scan est exécutée pendant la phase de développement. Pour les outils Open source, le défi reste le temps de traitements conséquents et le nombre de faux positifs à traiter. HP Fortify est très pertinent dans sa capacité de détection des problèmes majeurs mais Checkmarx reste leader sur la solution d’audit de code.

Gestion des vulnérabilités

Les librairies sont souvent utilisées et la gestion des patchs n’est pas souvent faite. Open Web Application Security Project (OWASP) propose un plugin dependency-check qui vérifie si une librairie est vulnérable.

Automatisation des tests de sécurité

Elle répond à quatre défis principaux présents dans le monde numérique à savoir :

  • La garantie de l’adéquation avec les expressions de besoin métier.
  • L’assurance et la confiance des applications.
  • L’accélération de la mise en production.
  • L’assurance des systèmes et de leur interopérabilité à travers des séries de tests.

Vision du produit /Service

Présentation du modèle SDLC sécurisé

La figure ci-dessous présente le modèle que doit respecter le SDLC global.

SDLC global sécurisé

Nous distinguons cinq étapes primordiales à respecter pour chaque phase du cycle de développement (SDLC).

Phase d’étude :Une mise en place des exigences de sécurité est menée afin d’assurer le cahier de charge défini. L’analyse de risques doit être établi afin de renseigner le besoin et de bien mener la phase de conception.

Phase de conception :Un ensemble d’architecture doit être implémentée pour une suivie guidée du modèle.

Phase de réalisation :L’analyse de code est menée. Cette analyse est automatisée et programmée.

Phase d’acceptation :Cette phase détermine si l’application est apte à passer en phase d’exploitation. Elle passe par le référent de sécurité présent dans la Digital Factory et par le RSSI et repose sur

  • La revue du cahier de charge, de recette de sécurité,
  • L’adéquation entre les preuves fournies et le cahier de recette,
  • L’approbation formelle de l’équipe de sécurité.
  •  
  • Phase de maintenance

Phase de maintenance :Elle comprend la phase de maintien en condition opérationnelle (MCO) et la phase de maintien en condition de sécurité (MCS).

  • Dans le cadre du maintien en condition opérationnelle, il est primordial d’intégrer un plan d’urgence et de poursuite d’activité, de définir un plan de sauvegarde et une gestion de patch.
  • Dans le cadre du maintien en condition de sécurité, il semble nécessaire de faire appel à l’équipe de sécurité des SI. Cette dernière se charge d’intégrer le projet suivant l’évolution du SI, de faire la gestion des vulnérabilités, d’identifier et d’intégrer les risques identifiés dans la matrice de gestion des risques.

Procédure

Elle se passe en trois phases majeures qui assurent l’adéquation des résultats.

Phase de mise en place :Elle correspond à la mise en place de l’intégralité des environnements. Elle englobe l’environnement de développement. Le QA se charge de gérer cette partie afin de contrôler les actions des développeurs.

Phase d’analyse :Elle correspond à la phase de lancement des scans. Nous distinguons différents types de scans selon le niveau de maturité de l’application. Le lancement se passe de manière automatisée.

Phase de validation : Elle correspond à la phase de validation de sécurité. Elle doit être menée par l’équipe sécurité des systèmes d’information (SSI). Selon les résultats obtenus, une recette de sécurité sera faite par l’analyste de sécurité.


Conclusion

L’automatisation des tests de sécurité attire de plus en plus de curieux. Son avantage est sa complexité car regroupant en un seul profil, trois types de profils différents à savoir : QA, développeurs et consultant en sécurité.

A l’heure actuelle et en tant que retour d’expérience, il reste un gros challenge de regrouper en une seule personne, un DevSecOps. Il est plus judicieux d’avoir dans un environnement de développement, un profil d’automaticien de test de sécurité avec la bonne proportion d’expertise afin de garantir en continuité le respect des exigences en termes de sécurité dans les projets de développement.

La sécurité est un domaine très vaste et le DevSecOps est une idéologie comme le DevOps qu’il faut bien maîtriser avant de s’y engager.