La recette efficace pour mettre en place la démarche DevSecOps

Published by Manon de Oliveira on

La recette efficace pour mettre en place la démarche DevSecOps

Par le passé, avec des démarches comme CMMI, cycle en V, la durée de construction et développement d’une application était de 2 à 3 ans. Aujourd’hui avec les méthodologies SCRUM, KANBAN, DevOps, cette durée est de 12 à 6 semaines. En effet, l’émergence des approches agiles a révolutionné le monde du développement logiciel.

Face à cette transformation, quelle est la démarche proactive à appliquer par le RSSI pour arriver à    suivre ce rythme rapide de livraison, tout en appliquant le concept « Security by Design » ?

Téléchargez le livre blanc

Comprendre le DevOps

Avant de nous plonger dans l’aspect sécurité, prenons un bref moment pour parler du DevOps.

Conceptualisé en 2009 en Belgique par l’informaticien Patrick Debois, le DevOps est un mouvement qui vise à concilier deux métiers : le développement logiciel (Dev) d’une part, l’administration de systèmes et d’architectures (Ops) d’autre part. DevOps est une combinaison de philosophies culturelles, de processus et d’outils qui améliore la capacité d’une entreprise à livrer des applications et des services à un rythme élevé.

devops
Figure 1 : le modèle DevOps

L’agilité, l’automatisation, l’intégration et le déploiement continus (CI\CD) sont les pierres angulaires de la démarche DevOps. Et la sécurité dans tout ça ?

Comprendre le DevSecOps

Le National Institute of Standards and Technology (NIST) fait état de 1000 à 10000 erreurs de programmation par million de lignes de code. Certes, ces erreurs n’entrainent pas forcement un impact sur la sécurité (confidentialité, intégrité, disponibilité), cependant, elles ont un impact sur la qualité des développements et les coûts de maintenance associées. Dans ce contexte, il est primordial de découvrir ces erreurs de programmations (dont les vulnérabilités sont potentiellement accessibles par une grande population) avant de passer en production.

Intégrer les aspects sécurité dans un cycle de développement logiciel est une réponse efficace à cette problématique. Elle permet d’élever le niveau de sécurité en réduisant les failles de sécurité et donc avoir des répercussions très bénéfiques sur le produit final : réduction des correctifs en production, réduction des risques de compromission de données privées et/ou personnelles, réduction des risques de perte d’image de marque …

Voir la sécurité comme une responsabilité partagée, intégrée du début à la fin du cycle de développement est la meilleure approche à suivre pour répondre à cet enjeu. D’ailleurs, c’est cette vision qui a donné naissance à l’expression « DevSecOps » pour souligner la nécessité d’intégrer la sécurité aux projets DevOps. Mais comment peut on implémenter la démarche DevSecOps dans une organisation ?

devsecops
Figure 2 : le modèle DevSecOps

Comment placer la sécurité dans une démarche DevOps ?

Le voyage de la démarche DevOps vers la démarche DevSecOps passe par 7 étapes :

outillage devsecops
Figure 4 : Outillage DevSecOps
1. Engagement de la direction

Le premier pas vers la réussite d’un programme DevSecOps est la création d’une équipe projet accompagnée par des experts en DevSecOps.

Cette équipe pilotera le programme et communiquera à tous les niveaux sa vision et ses objectifs.

Avant de se lancer dans l’aventure, il faut absolument avoir le soutien et le support de Top Management.

2. Périmètre DevSecOps

Notre conseil est de privilégier la qualité à la quantité. Réduire votre périmètre DevSecOps et partir sur un nombre d’applications restreint, vous aidera à implémenter la démarche DevSecOps efficacement, ainsi que récolter le fruit de votre travail rapidement.

Une fois que le périmètre initial est finalisé, vous pourrez étendre la démarche DevSecOps sur un scope plus large.

3. Culture DevSecOps

La culture DevSecOps se résume en trois mots : Confiance, Responsabilité, Coopération.

La confiance est efficace pour combler le fossé entre le monde DevOps et le monde de la sécurité. Et pour cela nous vous conseillons d’aller rechercher la motivation chez les développeurs et les administrateurs. Il faut aussi abandonner l’approche traditionnelle de droit de veto de l’équipe Sécurité et passer de la ‘surveillance’, toujours mal perçue, à l’engagement de la chaine de développement et de production, afin de créer une culture qui respecte les équipes de développement, de production et contribue à la confiance.

La responsabilité développeur de la sécurité de son travail est un élément clé de la culture   DevSecOps. Avec la sensibilisation aux failles et aux menaces qui pourraient potentiellement nuire aux applications, et le dialogue avec l’équipe sécurité, cette responsabilité ne peut que se renforcer.

La coopération est la troisième dimension de la culture DevSecOps. Pour créer une équipe unifiée axée sur DevSecOps, l’équipe de sécurité doit travailler et collaborer avec les développeurs et les administrateurs, et non pas les surveiller et les auditer.

4. Security Champions

L’équipe sécurité n’est pas dimensionnée pour accompagner chaque équipe de développement et de production sur les différentes problématiques de sécurité.

Avoir un correspondant de l’équipe de sécurité dans chacune de ces équipes est la meilleure solution pour assurer l’adhésion des développeurs et des administrateurs à la démarche DevSecOps. C’est ce qui correspond à qu’on appelle le Security Champion.

Son rôle est d’évangéliser la démarche DevSecOps et diffuser la culture sécurité auprès de son équipe, parmi ses responsabilités on trouve :

  • La contribution à la conception sécurisée de l’architecture applicatives ;
  • La veille au respect des bonnes pratique de sécurité des développements ;
  • La réalisation ou la vérification des revues de code ;
  • La rédaction de user stories orientées sécurité ;

La réussite du rôle Security Champion est conditionnée par deux facteurs : le temps, et la compétence.

Le Security Champion ne doit pas cumuler ce rôle avec un autre rôle majeur au risque que le rôle de Security Champion passe au second plan.

Le Security Champion doit avoir un état d’esprit lui permettant d’imaginer le comportement malveillant d’un attaquant, ainsi qu’avoir des connaissances techniques dans la sécurité applicative.

5. La station : Formation

Il y a plusieurs moyens pour aider les Security Champions à monter en compétence :

  • Programme de formation sur les sujets techniques et fonctionnels de la sécurité applicative ;
  • Coaching par un expert en sécurité informatique présent au niveau de l’entreprise ;
  • Communauté regroupant les Security Champions permettant l’entraide et l’autoformation.
6. La station : Automatisation

L’un des principaux composants de l’approche DevSecOps est l’automatisation. Elle permet de minimiser l’intervention humaine sur le cycle de développement des applications. Il s’agit d’industrialiser les vérifications de sécurité en supprimant le besoin de le faire manuellement au niveau de chaque développeur.

7. La station : Outillage

L’intégration de la sécurité dans la démarche DevSecOps, est réalisé tout au long du cycle de vie des applications ou de l’infrastructure.  Pour chaque phase de cycle de vie nous avons des familles d’outils.

Dans la phase « Code », on trouve les outils SAST[1], qui analysent le code source et essaient de trouver des patterns de vulnérabilités directement dans le code.

Dans la phase « Build », on trouve les outils SCA[2], qui analysent les dépendances, les composants externes du code source.

Dans la phase « Test », on trouve les outils DAST[3], qui génère des requêtes suivant des patterns d’attaques connues pour voir si l’application est vulnérable à ces types d’attaques.

Dans la phase « Operate », on trouve les solutions MFA[4], qui offrent le service de l’authentification multi facteur.

Dans la phase « Monitor », On trouve les solution SIEM[1], qui permettent de gérer et corréler les journaux pour des raisons de surveillance et monitoring.

[1] Static Application Security Testing

[2] Software Composition Analysis

[3] Dynamic Application Security Testing

[4] Mutli-Factor Autentication

Roadmap devsecops
Figure 3 : Roadmap DevSecOps

La liste des outils est loin d’être exhaustive, nous vous conseillons de choisir les outils qui     s’alignent avec votre contexte technique.

Nous vous conseillons aussi de ne pas vous lancer dans l’implémentation de plusieurs outils DevSecOps (SAST, SCA, DAST, …) au même temps, commencez dans un premier temps par un outil SAST, une fois maitrisé vous pourrez dans un deuxième temps tester des nouveaux outils. Ne pas oublier que la méthode DevSecOps s’inscrit dans une démarche à amélioration continue.

Conclusion

Contrairement aux idées reçues, le DevSecOps ne se résume pas à l’automatisation des tests de sécurité mais consiste en une intégration de la sécurité tout au long du cycle de vie des applications ou de l’infrastructure.

Pour conclure et synthétiser comment mettre en place une démarche DevSecOps efficacement, il est indispensable de passer par les sept étapes décrites ci-dessus.

Pour améliorer la maturité de votre démarche DevSecOps, nous vous conseillons de consulter notre Livre Blanc : DevSecOps : de la culture à la maturité opérationnelle ?

Téléchargez le livre blanc

Othmane ERRAJI

Consultant confirmé EVA Group

consultant eva group
Categories: EVATECH