Alors que l’adoption de DevOps pour des organisations Agile était une transition naturelle, le passage à DevSecOps a introduit de nouveaux défis. DevSecOps nécessite un changement important de mentalité et de culture d'entreprise pour intégrer les nouveaux outils et les nouvelles activités de sécurité. C’est la raison pour laquelle suivre le rythme d’Agile et la culture DevOps lors de l’introduction de la sécurité dans le cycle de développement logiciel (SDLC) est un défit pour de nombreuses entreprises. Dans ce webinaire, Cem Nisanoglu explore le modèle opérationnel de DevSecOps et souligne l'importance de la gestion des changements, de l'automatisation, et des indicateurs de sécurité dans une transition vers DevSecOps, ainsi que la manière dont ces activités peuvent contribuer à la formation de sécurité, à des cycles de release plus rapides, et à l'optimisation des budgets de sécurité dans l’entreprise.

1. CONFIDENTIAL© 2019 Synopsys, Inc.1
Sécurité Applicative et DevSecOps dans un
monde Agile
Cem Nisanoglu
Managing Consultant
(Associé Cyber Sécurité)

2. CONFIDENTIAL© 2019 Synopsys, Inc.2
Introduction…
Mon rôle chez Synopsys:
- Je suis le responsable des services de sécurité applicative dans la région de l’Europe du Sud, qui inclut la
France.
- Je travaille avec une équipe de consultants talentueux pour prendre en charge les challenges les plus
difficiles en matière de sécurité applicative pour nos clients.
Ancien Parisien, actuellement basé à Londres.
Cem Nisanoglu
Managing Consultant
(Associé Cyber Sécurité)
Plus de 17 ans dans divers rôles, y
compris le développement,
l'architecture, développement mobile,
sécurité applicative et conseil.

3. CONFIDENTIAL© 2019 Synopsys, Inc.3
Agenda
• DevSecOps
– Quelques définitions
– Modèle opérationnel
• Mesurer son programme de sécurité
applicative
– BSIMM
– Software Security Group (SSG)
– Satellites
• Programme des champions
– Formation
– Base de connaissance, standards de
sécurité, et programmation défensive
• KPI/KRI (Indicateurs de performance et
risque)
– Meilleures pratiques et pièges à éviter
• Budget
– Coût de la remédiation
– (Création/utilisation) des bibliothèques de
sécurité

4. CONFIDENTIAL© 2019 Synopsys, Inc.4
Agile CI/CD DevOps
Est un(e) Process
Support pour le cycle
de développement
logiciel
Culture
Met l'accent sur Changement Outils Rôles
Fournit Rapidité Automatisation Réactivité, triage
Quelques définitions…
Agile DevOpsCI/CD

5. CONFIDENTIAL© 2019 Synopsys, Inc.5

6. CONFIDENTIAL© 2019 Synopsys, Inc.6

7. CONFIDENTIAL© 2019 Synopsys, Inc.7
Comment une organisation peut-elle connaitre le
niveau de maturité de son programme de
sécurité applicative ?

8. CONFIDENTIAL© 2019 Synopsys, Inc.8
Le modèle descriptif vs. prescriptif
Les modèles prescriptifs
• Décrivent ce que vous devriez faire.
- SAFECode
- SAMM (anciennement OpenSAMM à OWASP SAMM)
- SDL
- Touchpoints
• Chaque entreprise a sa méthodologie
(souvent hybride).
• Vous avez besoin d'un SSDL (Secure
Software Development Lifecycle).
Les modèles descriptifs
• Décrivent ce qui se passe réellement.
• Le BSIMM est un modèle descriptif qui peut
être utilisé pour mesurer un nombre illimité
de listes SSDL normatives.
https://bsimm.com

9. CONFIDENTIAL© 2019 Synopsys, Inc.9
Pourquoi BSIMM ?
• Il s’agit d’un modèle de maturité créé à partir des données réelles
recueillies à partir de 120 initiatives de sécurité applicative.
• Le modèle a été validé avec les données de 167 entreprises (120
dans BSIMM9) à travers 389 audits.
• Permet de mesurer 116 activités de sécurité par observation.
• Permet de visualiser les activités en trois niveaux.
• Permet de construire un tableau de bord comparatif.

10. CONFIDENTIAL© 2019 Synopsys, Inc.10

11. CONFIDENTIAL© 2019 Synopsys, Inc.11
BSIMM : Un framework pour sécurité applicative
https://bsimm.com
4 Domaines 12 Pratiques

12. CONFIDENTIAL© 2019 Synopsys, Inc.12
La liste des activités dans BSIMM

13. CONFIDENTIAL© 2019 Synopsys, Inc.13
Résultats BSIMM9

14. CONFIDENTIAL© 2019 Synopsys, Inc.14
Software Security Group (SSG)
Equipe de sécurité applicative (SSG): Groupe interne chargé
d’assurer et de faciliter la sécurité des applications. Selon nos
observations, la première étape d'une initiative de sécurité
applicative (SSI) consiste à former un groupe de sécurité.
Un satellite est un groupe de personnes qui ne travaillent pas
directement pour le SSG, mais qui contribuent néanmoins à des
efforts de sécurité quotidiens pour la sécurité des applications.
Satellite

15. CONFIDENTIAL© 2019 Synopsys, Inc.15
L’âge de l’initiative (SSI) (années) La taille du satellite (personnes)
Moyen : 4.13 Moyenne : 52.4
La plus récente : 0.1 La plus petite : 0
La plus ancienne : 19 La plus grande : 2,250
Médiane : 3.0 Médiane : 0
La taille de SSG (personnes)
La taille de l’équipe de développement
(personnes)
Moyenne : 13.3 Moyenne : 3,463
La plus petite : 1 La plus petite : 20
La plus grande : 160 La plus grande : 45,000
Médiane : 5.5 Médiane : 900
Statistiques réelles des 120 entreprises
Pourcentage moyen de SSG au développement est de 1,33
(1 personne pour 75 développeurs), médiane de 0,67

16. CONFIDENTIAL© 2019 Synopsys, Inc.16
Les défis récurrents des SSG (1/2)
Echelle
Difficile de trouver des
professionnels de sécurité
applicative.
Ecarts dans la couverture du
portefeuille d'applications.
Problèmes pour traiter la dette
technique lié à la sécurité.
Charge élevée de consultation
pour la SSG.
Agile
La sécurité peine à suivre
le rythme des pratiques
de développement agiles.
Problèmes liés à
l'adoption d'un outil de
sécurité ou des activités
dans les équipes de
développement.
Developer relations
La communication avec
le développement est
réactive et n’est pas
collaborative.
La sécurité s'engage en
fin de cycle de
déploiement.
Une intervention réactive
entraîne des retards de
déploiement.

17. CONFIDENTIAL© 2019 Synopsys, Inc.17
Les défis récurrents des SSG (2/2)
L’approche adoptée par Synopsys pour implémenter DevSecOps prend en compte les défis
organisationnels à l’avance afin de créer la voie d’une transition transparente. Cela signifie
qu’il faut anticiper le plus grand nombre possible de points de friction pour que les contrôles
et les pratiques de sécurité des applications suivent le rythme du développement.
Pour sécuriser le SDLC et passer à DevSecOps, l’entreprise doit implémenter divers
contrôles de sécurité à travers des personnes, des processus et des technologies. Le
succès de cette mise en œuvre sera lié à la rapidité avec laquelle l’organisation peut
adopter de nouvelles technologies et de nouveaux processus et son agilité d’adapter au
changement, plaçant la gestion du changement au cœur de l’opération.

18. CONFIDENTIAL© 2019 Synopsys, Inc.18
Programme de Champions de Sécurité

19. CONFIDENTIAL© 2019 Synopsys, Inc.19
Pourquoi un programme de Champions de Sécurité ?
• Favoriser une relation positive avec les développeurs via des champions de
sécurité pour transformer la perception du SSG de « flics » en facilitateurs.
• Intégrez les champions de sécurité dans chaque équipe de développement.
• Adopter une approche plus proactive à la sécurité applicative.
• Profitez des champions de sécurité pour aider à mener et à faire évoluer diverses
activités et initiatives de sécurité dans le cycle de développement (par exemple,
Threat Modeling (modélisation), adoption des outils de sécurité dans le pipeline
CI / CD, etc.)

20. CONFIDENTIAL© 2019 Synopsys, Inc.20
Champions de Sécurité – Critère de sélection
Quelques sont les qualités d’un champion de sécurité :
• CDI avec l'expérience en développement.
• Idéalement 3-5 ans en développement, très performant.
• Solides compétences en communication et en une bonne connaissance de
l’organisation.
• Démonstration d'aptitude à la sécurité applicative.
• Motivé.

21. CONFIDENTIAL© 2019 Synopsys, Inc.21
Champions de Sécurité – Process de Sélection
Nomination Qualification Entretien Inscription
1. Le directeur nomme un développeur qualifié.
2. L'administrateur du programme examine le candidat.
3. Si le candidat satisfait tous les critères, il est interrogé par l'équipe de sécurité applicative.
4. Si le candidat passe l'entretien, il est inscrit au programme.

22. CONFIDENTIAL© 2019 Synopsys, Inc.22
KPI/KRI (Indicateurs de performance et risque)

23. CONFIDENTIAL© 2019 Synopsys, Inc.23
Pourquoi est-il compliqué d’établir des indicateurs ?
Des exemples de mauvaises questions à se poser pour établir les
indicateurs :
• Quel est le nombre de bogues dans le logiciel que nous développons?
– C'est une "mauvaise" question parce que… le nombre de bogues seul ne tient pas compte de la
gravité du risque ou de la taille de votre portefeuille d'applications.
• Combien de temps nous faut-il pour récupérer d'un incident de sécurité?
– C'est une "mauvaise" question parce que… ceci est en grande partie hors de votre contrôle; il peut
varier en fonction du type de l’incident de sécurité.

24. CONFIDENTIAL© 2019 Synopsys, Inc.24
Quelques conseils…
Doit
• Mesurer la conformité au
cycle de développement
logiciel.
• Obtenir la télémétrie des
portes primaires.
• Créer une boucle de
rétroaction pour
l'améliorer le SSDL.
• Regardez les données!
• Considérer les facteurs de
l'exécution du programme
et les risques
Devrait
• Corréler les données.
• S'efforcer d'obtenir de
bonnes données
chronologiques.
• Comparer la valeur des
efforts.
• Testez vos théories /
intuition.
• Racontez votre histoire
App Sec.
• Corrigez vos métriques
quand vous savez qu'elles
sont fausses.
• Maximiser l'impact des
dépenses sur la sécurité.
Devrait éviter
• Compliquer
accidentellement les
chiffres.
• Compliquer
intentionnellement les
chiffres.
• Précipiter le
développement des
métriques.
Ne doit pas
• Fabriquer des chiffres.
• Inventer des histoires sur
des chiffres fabriqués.

25. CONFIDENTIAL© 2019 Synopsys, Inc.25
Budget

26. CONFIDENTIAL© 2019 Synopsys, Inc.26
Coût de la remédiation
L'intégration de contrôles de sécurité plus tôt dans le process du développement permettra de réduire le coût total du
développement logiciel. D'après un article de 2017 publié sur Dark Reading (en collaboration avec nos chercheurs), le
coût de la réparation des failles évités représente une nette économie de productivité, car aucun délai de réparation par
le développeur n'est nécessaire en l'absence de tout défaut. Le coût estimé de la réparation d'un défaut pour chaque
phase de développement logiciel est détaillé ci-dessous:
Coût de réparation d’une faille pour chaque phase de développement
https://www.darkreading.com/perimeter/the-economics-of-software-security-what-car-makers-can-teach-enterprises-/a/d-id/1329083

27. CONFIDENTIAL© 2019 Synopsys, Inc.27
SSG: Vers un modèle distribué

28. CONFIDENTIAL© 2019 Synopsys, Inc.28
Les Assises 2019
Au Cœur de la
Communauté Cyber
Grimaldi Forum
10 Av. Princesse Grace, 98000 Monaco
9/10/19 – 12/10/19
sw-integrity-events@synopsys.com

29. Thank You Merci