développements: Atouts et maillons faibles

Transcription

1 Clusir RhA groupe SSI ENE 24 novembre 2010 Sécurité dans les projets et développements: Atouts et maillons faibles Yves RAISIN / BIOMERIEUX Sébastien RAILLARD / COEXSI Lionel PRADES / LEXSI

2 Sécurité des services applicatifs: Constats et Objectifs Objectif SDLC, les méthodologies, l alignement li Focus proposés: MOA et Sécurité, développement, production Conclusions: Les incontournables, les voies de l amélioration AGENDA Page 1

3 Le même constat toujours renouvelé : Page 2

4 Des préoccupations divergentes des acteurs «Les clients ne mentionnent jamais dexigences d exigences de sécurité, il faut les extorquer» => Il faut qu ils les comprennent Les développeurs ne pensent pas comme des hackeurs => Créer une fonctionnalité vs Détourner l usage Les acteurs du SDLC (software development e e life cycle) sont peu incités à renforcer la sécurité => Fragmentation des responsabilités Les stratégies sécurité prennent encore peu en compte que les attaques se déplacent massivement vers le niveau applicatif (dans un contexte où ces applications sont largement exposées) Page 3

5 et des menaces en évolution rapide avec des conséquences parfois lourdes La pression de la recherche augmente le nombre de 0D Le nombre de vulnérabilités découvertes au niveau applicatif augmente relativement aux couches inférieures L exploitation des vulnérabilités s industrialise et se diffuse plus pus rapidement e WhiteHat Website Security Statistics Report : (données relevées entre jan et oct sites web) 83% des sites web ont souffert d au moins une vulnérabilité classée urgente, critique ou haute selon PCI-DSS 64% des sites web souffrent actuellement d une telle vulnérabilité é Page 4

6 Les Objectifs Couvrir les menaces: Attaques externes et internes sur les frontaux en production Attaques sur les programmes installés, notamment clients Bugs logiciels Attaque / Infection des sources / systèmes de gestion de versions Réduire les vulnérabilités produites / disponibles SDLC: Conception, Développement, Intégration, Mise en production Produire le service et les mesures de sécurité adaptés aux besoins du client!! Page 5

7 Sécurité des services applicatifs: Constats et Objectifs Objectif SDLC, les méthodologies, l alignement li Focus proposés: MOA et Sécurité, développement, production Conclusions: Les incontournables, les voies de l amélioration AGENDA Page 6

8 Une proposition de méthodes pour tous Des lignes directrices et des méthodes pour tous US NIST SDLC FR ANSSI GISSIP BSIMM 2 OpenSAMM : Software Assurance Maturity Model open framework de l OWASP lowasp Microsoft Security Development Lifecycle En utilisez vous d autres? dau Reste à choisir les outils adaptés Page 7

9 US NIST Special Publication Rev2 Security Considerations in the System Development Life Cycle 3 e édition (2003, 2004, 2008) Couvre tout le cycle de vie (avantprojet au retrait) Propose des modèles d organisation (responsabilités) Propose des listes de contrôle assez génériques Définit chaque process et activité (pré-requis, objectifs) Plutôt orienté grands projets / grandes organisations Requiert les autres documents du référentiel pour les détails Page 8

10 France ANSSI GISSIP : Guide d Intégration de la Sécurité des SI dans les Projets Cycle générique adapté à toute méthode projet Très structurée / niveaux de maturité Guide de haut niveau facile à s approprier Orientée liste d actions, formalisation et homologation Identifie rapidement bases de bonnes pratiques Focus plutôt amont Référence outils externes A assouplir et adapter au contexte Page 9

11 BSIMM v2 : Building Security In Maturity Model Benchmark for Software Security Framework 3 chercheurs / 30 entreprises A adapter à son organisation Pas une méthodologie, mais recueil BP et selon ses objectifs Benchmark => Modèle statistique 12 pratiques en 4 domaines: 109 activités classées pour différents niveaux Page 10

12 OWASP Open SAMM Software Assurance Security Maturity Model (v1 2009) Club indépendant entreprises / Individus id Cherche cohérence dans l amélioration en couches homogènes Outillage plus complet avec feuille de route et outils de mesure Dédié développement logiciel Adapté à l évolution lente des organisations S organise autour des itérations Fournit des détails, mais le tailoring est nécessaire Page 11

13 Les Bonnes Pratiques à adopter L approche par bonnes pratiques et modèle de maturité permet de répondre au challenge de lintégration l intégration de la sécurité, encore faut-il poser et répondre aux questions suivantes: Où en sommes nous? S évaluer Quel niveau de maturité devons nous atteindre? Répondre à des enjeux Quels moyens devons nous mettre e en œuvre pour y parvenir? Quelles sont les priorités L analyse des partenaires en présence est nécessaire pour réussir un alignement de chacun: Quelle compréhension? Sensibilisation / Communication Quelles responsabilités? Support management, contractualisations Quels moyens? Amélioration progressive et démonstration d efficacité Critères: Coûts, ressources, compétences, délais, réduction de risque ROI? Page 12

14 ROI: L exercice du retour sur investissement «Reworking a software requirements problem once the software is in operation typically costs 50 to 200 times what it would take to rework the problem in the requirements stage» (Boehm and Papaccio 1988) Mettre en place des métriques Pour mesurer l évolution Pour justifier la démarche Choisir le 80/20 Etre préparé à la résistance Page 13

15 Sécurité des services applicatifs: Constats et Objectifs Objectif SDLC, les méthodologies, l alignement li Focus proposés: MOA et Sécurité, développement, production Conclusions: Les incontournables, les voies de l amélioration AGENDA Page 14

16 Focus sur certaines phases Etude: Organiser le projet Collecter les enjeux (de façon homogène) Faire une analyse correcte des besoins de sécurité Conception et Réalisation: Usage de catalogues de solutions et d architecture Production de code secure Mise en Production: Configuration Gestion de correctifs Page 15

17 Les Enjeux Intégrer la SSI à la gestion de projet Le plus en amont possible En impliquant les métiers l informatique la sécurité informatique En définissant ensemble les bonnes exigences de sécurité Penser à une sécurité homogène en étant exhaustif Page 16

18 Les opportunités Avoir une double responsabilité (sécurité/méthodologie) Faire adhérer les métiers Comprendre les menaces Analyser les vulnérabilités, la probabilité d occurrence, l impact Réfléchir aux plans de marche dégradés Sensibiliser Utiliser le levier de la Qualité Réglementation FDA Continuité d activité Page 17

19 Les livrables Les accords de confidentialité L évaluation des domaines de sécurité L analyse des enjeux de sécurité Réglementation ti Archivage Confidentialité Intégrité Disponibilité Microsoft Excel Worksheet Le contrat juridique La mesure des contrats de services Page 18

20 Les bénéfices La sensibilisation des métiers L accord préalable entre métiers et informatique L architecture qui en découle La gestion des dépendances L optimisation des coûts Les plans de reprise d activité i La gestion du patrimoine Page 19

21 Les axes d amélioration Les analyses de risque Les domaines fonctionnels manquants La mesure du Retour Of Security Investment Page 20

22 Sécurité des services applicatifs: Constats et Objectifs Objectif SDLC, les méthodologies, l alignement li Focus proposés: MOA et Sécurité, développement, production Conclusions: Les incontournables, les voies de l amélioration AGENDA Page 21

23 Sécurité dans les développements Caractéristiques d un développement interne Impact des choix technologiques Organisation des développements Gestion des accès Mise en production Exemple des applications WEB Page 22

24 Caractéristiques d un développement interne Application propre à la structure : Développement sur mesure Hors cycle du support des éditeurs Réalisation en interne ou externalisée Types d application : Macros dans documents type «office» Client lourd Intranet Extranet Site publique Batch de traitement hors ligne Périmètres : Type d utilisateur : interne, partenaire, externe (public) Accessible depuis les réseaux internes et/ou externes Beaucoup de combinaisons possibles! Page 23

25 Impact des choix technologiques Langages de développement Langages «modernes»vs vs. «anciens» Facilité de lecture, débogage, audit Protections inhérentes Contextes d exécution (compilé, interprété, natif, virtualisé) Librairies externes : Très grande variété : API natives Livrées avec l environnement de développement Frameworks Confiance Support efficace pour correction failles (et bugs) Environnement d exécution des librairies Personnalisation d un outil Base fournie par un éditeur Personnalisation par configuration ou développement de plugins Page 24

26 Organisation du développement Environnements Bien dissocier les environnements Définition de règles de passage entre environnements Développer avec des jeux de données non critiques Outils de modélisation Modéliser les données Modéliser les traitements (penser aux situations critiques) Outils de tests automatisés Détection de vulnérabilités Détection de pratiques non recommandées Basées sur des règles personnalisables Charte des développeurs Règles de développement Validation du code (relecture) Page 25

27 La gestion des accès Le casse-tête : Souvent, pas de matrice simple Multidimensionnel avec exceptions (positives et négatives) Interconnexion : La base d identification / authentification souvent externe Parfois, éclatement du stockage des droits Problèmes des droits spécifiques à une application Intégration dans une politique «SSO» Expérience utilisateur : Travail aa en amont otetaa aval : Afficher les options et documents uniquement autorisés Vérifier que les requêtes soient valides Intégration au systèmes d authentification existants Page 26

28 Mise en production Cas des développeurs Situation «juge et partie» Généralement, résultats les plus risqués Orientation très fonctionnelle Cas des exploitants Contrôle de la conformité technique du travail livré Généralement en coordination avec la sécurité (besoin d accès) Orientation conformité à l environnement de production Intégration des problématiques de surveillance, sauvegarde Soucis en cas d utilisation de technologies non maîtrisées Problème des paramétrages par défaut Peuvent êtres très laxistes (moins vrai) Peuvent être trop stricts et entrainer des désactivations critiques Page 27

29 Exemple des applications WEB Situation très courante Travailler sur des jeux de règles simples mais efficaces : Ne jamais faire confiance au contenu envoyé! Toujours vérifier le format et les valeurs envoyées Utiliser des «Stored Procedures» et les échappements de chaines Echapper les chaines HTML affichées Ne jamais exposer les chemins de fichiers locaux Ne pas négliger la gestion des sessions Seul moyen de regrouper les requêtes web disparates par définition Faire attention t aux données exposées (cookies) Vérifier la mécanique de gestion des sessions et leur authentification Un pare feu protège rarement une application web : Par défaut, port 80 simplement ouvert Difficulté d analyse du trafic SSL Difficulté de mise en place un filtrage applicatif efficace Solutions de filtrage à base de règles génériques et connues Page 28

30 Sécurité des services applicatifs: Constats et Objectifs Objectif SDLC, les méthodologies, l alignement li Focus proposés: MOA et Sécurité, développement, production Conclusions: Les incontournables, les voies de l amélioration AGENDA Page 29

31 Déploiement et maintenance Retour dexpérience d expérience : 100% de réussite des pentests 3 gisements exploités prioritairement: Configuration Vulnérabilités logicielles non corrigées Défauts et faiblesses applicatifs Réduire la surface d exposition des services Socles durcis et maintenus, Services, comptes, mots de passe Ne pas laisser d outillage ou d information accessible Pentester avant la mise en production, puis régulièrement «Dommage de gâcher le travail pour des choses simples» Page 30

32 Sécurité des services applicatifs: Constats et Objectifs Objectif SDLC, les méthodologies, l alignement li Focus proposés: MOA et Sécurité, développement, production Conclusions: Les incontournables, les voies de l amélioration AGENDA Page 31

33 Nos conseils : du bon sens Connaissez bien les enjeux de votre SI, et vos partenaires pour adapter les actions d amélioration choisies à la capacité actuelle de chacun. Adoptez la méthodologie de votre organisation ou n importe quelle générique, et utilisez les blocs d un modèle de maturité pour vous améliorer Ne négligez aucun des blocs (impacts divergents des oublis), et soignez les étapes proches de la mise en production (faible coût, facile à automatiser). Intégrer l'expression des exigences de sécurité en phase amont des projets (pré-projet) Etre teexhaustif sur les esdomaines escouverts ets Challenger le business Utiliser des règles simples, cohérentes Ne pas multiplier les règles, rester concis et efficace Etre pragmatique, ne pas oublier son bon sens Page 32