Web éducation Intégrer la sécurité dans le cycle de vie d’un système La sécurité des applications 18 octobre 2007 Luc Poulin M.Sc CISSP-ISSMP CISA.

Présentation au sujet: "Web éducation Intégrer la sécurité dans le cycle de vie d’un système La sécurité des applications 18 octobre 2007 Luc Poulin M.Sc CISSP-ISSMP CISA."— Transcription de la présentation:

1 Web éducation Intégrer la sécurité dans le cycle de vie d’un système La sécurité des applications 18 octobre 2007 Luc Poulin M.Sc CISSP-ISSMP CISA ift.a Conseiller senior Chef de la sécurité du CRIM

2

3 Problématique à l’intégration de la sécurité dans le cycle de vie d’un système
Les projets ont généralement un budget et une planification très serrés! La sécurité n’ajoute aucune fonctionnalité, performance ou convivialité; L’environnement technologique est de plus en plus complexe; On va commencer par faire fonctionner le système et on verra ensuite pour la sécurité; Les administrateurs ne comprennent pas toujours la portée d’un projet en sécurité et se sentent souvent dépassés lorsqu’ils la comprennent! Il faut se conformer au contexte d’affaires, à la loi et au système par lequel l’organisation pourrait être vérifiée. Ça ajoute un niveau de confiance par rapport à un PP. Concerne le principe de la responsabilité des efforts.

4 Un des défis, savoir gérer des buts divergents
Buts des projets de développement d’applications Fonctionnalité Convivialité Efficacité Développement rapide Simplicité Faible coût Buts de la sécurité dans les applications Prévention Traçabilité Surveillance Confidentialité Sécurité multi-niveaux Authentification Intégrité Etc.

5 Définitions Application d’affaire Types de données But de la Sécurité
Une application d’affaire est une application qui aide les organisations à automatiser leurs processus ou fonctions d’affaires. Les processus d’affaires inclut les personnes et la technologie. (Vision systémique) Types de données Normales Critiques (sensibles ou confidentielles) But de la Sécurité Protection des informations critiques de l’application Contexte d’exécution cible Le contexte d’exécution correspond à l’environnement technologique, d’affaires et juridique dans lequel fonctionnera le système ou l’application. Niveau de confiance (AL, niveau d’assurance) Contrôle et valide si les mesures de sécurité de l’application, identifiés par l’analyse de risque de l’application, ont toutes été correctement réalisées. Cible de sécurité (ST) La ST constitue la base de l’accord entre toutes les parties (développeurs, utilisateurs, évaluateur, gestionnaires, etc.) sur les services de sécurité offerts par la RI, de même que l’ampleur de l’évaluation. Profils de protection (PP) Un profil de protection définit un ensemble d’exigences de sécurité, indépendant de l’implémentation, et contient une formulation du problème de sécurité destiné à être résolu.

6 La sécurité de l’information et l’organisation
*..* 1..* Processus d’affaire Besoin d’affaire M / O Contexte juridique Critique Contexte d’affaire Actif informationnel Contexte Technologique 1..* Matériel Système Applications Données Critique Personnes Processus Technologies Informations Ressource informationnelle

7 Une vision globale des domaines de connaissance
Gestion de la sécurité (Gouvernance) Sécurité informationnelle Sécurité informationnelle Technologie (Acquisition, maintenance et contingence) Ressources Informationnelles critiques Systèmes (Développement et évolution) La sécurité c’est globale, et tous les domaines sont impactés par tous les secteurs. Vérification et contrôle (Conformité)

8 Que devons nous faire pour développer un système en lequel nous aurons confiance?
Un projet de développement de système doit s’assurer de couvrir adéquatement les besoins de sécurité provenant des quatre domaines de connaissances, selon le niveau de confiance désiré, en tenant compte du type de données et du contexte d’exécution cible. Il faut aussi être en mesure de prouver l’atteinte du niveau de confiance visé. Click – Surligner : …être en mesure d’en faire la preuve.

9 Objectifs de la sécurité des applications – besoins des utilisateurs…
Répondre aux besoins de sécurité des : Gestionnaires Gestionnaires de projets, Administrateurs, Détenteur de l’application, Gestionnaires, etc.. Leurs besoins : Quels sont les coûts supplémentaires de l’implémentation et du maintient de la sécurité de cette application (argent, effort) en relation avec les risques et sa valeur pour l’organisation ? Donnez-moi une preuve que l’application à atteint et maintient le niveau de confiance ciblé.

10 Objectifs de la sécurité des applications – besoins des utilisateurs…
Répondre aux besoins de sécurité des : Développeurs Architectes, Analystes, programmeurs, testeurs, etc. Leurs besoins : Quelle est la mesure de sécurité à appliquer à chaque phase du cycle de vie de l’application ? Pourquoi appliquer cette mesure à cette phase ? Comment dois-je réaliser le travail ?

11 Objectifs de la sécurité des applications – besoins des utilisateurs…
Répondre aux besoins de sécurité des : Auditeurs Contrôleurs financier, auditeurs, etc. Leurs besoins : Qu’est-ce que j’ai à vérifier, quand, ou ? Le résultat de l’audit doit être répétable et indépendant de l’auditeur Comment réaliser l’audit ?

12 Objectifs de la sécurité des applications – besoins des utilisateurs…
Répondre aux besoins de sécurité des : Utilisateurs Organisations, employés, utilisateurs finaux, etc. Leurs besoins : Est-ce sécuritaire de mettre mon information dans cette application ? Dois-je avoir confiance à ce truc ? Prouvez-le !

13 Les personnes Les processus La technologie
Les trois piliers de la sécurité, par ordre d’importance, en vue de protéger les informations Les personnes Les processus La technologie

14 1. Les personnes (acteurs)
Les trois piliers de la sécurité, par ordre d’importance, en vue de protéger les informations 1. Les personnes (acteurs) Incluent les utilisateurs, les développeurs, les techniciens, les gestionnaires, les administrateurs de systèmes… Tout le monde quoi! Appliquent, analysent ou implémentent les mesures de sécurité. Peuvent contourner ou insérer des failles de sécurité. Doivent être sensibilisées à leurs responsabilités, à l’importance de la sécurité et à l’impact de leurs actions ou de leur inaction sur celle-ci.

15 Les trois piliers de la sécurité, par ordre d’importance, en vue de protéger les informations
2. Les processus La sécurité est principalement un ensemble de processus. politique de sécurité; analyse de risque; cadre de gestion de la sécurité; gestion des identités et des privilèges d’accès; audits; contingence; etc.

16 Les trois piliers de la sécurité, par ordre d’importance, en vue de protéger les informations
3. La technologie Offre un ensemble d’outils pouvant être mis en place pour compléter, vérifier ou automatiser certaines mesures de sécurité exigées par la Politique de sécurité ou la cible de sécurité de la ressource informationnelle.

17

18 Pré requis essentiels à la sécurité logicielle
Monter un cadre normatif pour votre organisation Adopter et appliquer une méthodologie de développement en génie logiciel de très bonne qualité Y intégrer des mesures de sécurité pour vos applications Nommer un détenteur du système ou de l’application à développer Nommer un responsable de la sécurité pour le projet

19 Comment ces incontournables influencent la sécurité du système
MSA

20 La mesure de sécurité de l’application (MSA)

21 La mesure de sécurité de l’application (MSA)
MSA Identification Nom, identifiant unique, ses parents, ses enfants, etc. (auteurs, date, description, version…) Objectifs Indique pourquoi cet MSA existe, identifie les besoins, précise ce qui va être vérifié, etc. à quel niveau de confiance cet MSA est actif. (plus d’un niveau?) à quelle phase de quelle norme est associé cet MSA. (ITIL, Cobit, ISO17799, RUP, design pattern, etc.)

22 La mesure de sécurité de l’application (MSA)
Activité Description de l’activité, présente les processus et acteurs nécessaires pour implémenter et évaluer cette mesure. complexité, qualification requise par les acteurs, description du bien produit et résultats attendus, coût de l’activité, etc. Contrôle Description de l’activité de vérification, présente qui vérifie quoi, coût de l’activité de contrôle, précise si une vérification périodique est requise, etc..

23 Liste des MSA de l’organisation pour tous les niveaux de confiances

24 Principaux acteurs de l’équipe de réalisation

25

26 Cadre normatif de l’organisation – Cycle de vie générique

27 1. Préparation 2. Évaluation 3. Définition 4. Spécification 5. Conception 6. Réalisation 7. Transition 8. Déploiement 9. Production 11. Élimination 10. Mise à la retraite

28 Phase : 1. Préparation Identification du cadre de gestion et de réalisation du projet
Avant projet connaître le contexte d’affaire identification des environnements nécessaires au projet identifier le détenteur identifier les responsables de la sécurité, PR* identifier les lois, règlements et politiques concernant l’env. de production cible

29 Phase : 2. Évaluation Initialisation du projet
identifier et catégoriser sommairement les informations qui seront traitées par le système réaliser une analyse d’enjeux initiale de l’application (risques de haut niveau) afin d’ identifier le niveau de confiance cible et les MSA correspondant identifier les besoins de sécurité identifier le niveau de qualité de service désiré : système, environnements (ITIL) évaluer les coûts et les efforts associés aux activités de sécurité et à l’ajout de ces préoccupations dans les activités habituelles d’un projet obtenir l’approbation du détenteur Ensemble des activités précédant l’approbation d’un projet Réaliser une analyse de risque initiale analyser les menaces, les impacts et les contre-mesures possibles estimer les coûts et bénéfices des contres-mesures

30 Analyse d’enjeux / de risques de l’application

31 Phase : 3. Définition Mise en place du cadre de gestion et de réalisation du projet Définition des besoins et des spécifications du système Analyse fonctionnelle et planification définir la portée (faire, ne pas faire) définir les besoins de sécurité proposer un plan de vérification de la sécurité (check points) identifier les plans de qualité de service à automatiser définir les tests d’acceptation en y incluant les tests de sécurité ajuster, préparer et mettre en place l’environnement de développement Phase : 3. Définition Analyse fonctionnelle et planification vision et objectifs politiques et exigences de haut niveau définir les besoins de sécurité proposer un plan de vérification de la sécurité (check points) identifier les plans de qualité de service à automatiser redémarrage automatique des services critiques double sauvegarde des données exécution concurrentes de certains services etc. plans préliminaires de tests de sécurité Définir la porté du système doit définir ce que le logiciel doit pouvoir faire et pourquoi doit définir ce que le logiciel ne doit pas pouvoir faire et pourquoi développer des plans de relève Ajustement, préparation et mise en place de l’environnement de développement permet de définir les spécifications du logiciel mauvais ex.: « Doit utiliser le chiffrement lorsque nécessaire. » permet de définir les tests d’acceptation en y incluant les tests de sécurité inclure les fonctionnalités de base du système ajustement, préparation et mise en place de l’environnement de développement permet de définir les tests d’acceptation spécifications de sécurité = politique et règles de sécurité Sans spécification, un logiciel ne peut pas être jugé mauvais!

32 Phase : 4. Spécification Spécification de l’architecture du système
inventorier et classifier les données définir les spécifications de sécurité choix des mesures de sécurité et de PR* mettre à jour les plans de tests qui doivent inclure la sécurité considérer l’impact du langage sur la sécurité du logiciel développé sélectionner des normes de développement sécuritaire en fonction des langages choisis identifier les attaques possibles (arbre d’attaque) former les développeurs Phase : 4. Spécification Spécification de l’architecture du système architecture préliminaire inventaire et classification des données définir les spécifications de sécurité Identifier les modules critiques qui devront être vérifiés (Librairies, paquetages, etc.) choix des mesures de sécurité et de PR* mettre à jour les plans de tests qui doivent inclure la sécurité considérer l’impact du langage sur la sécurité du logiciel développé choisir les langages et identifier les forces et faiblesses de chacun d’eux gestion manuelle des pointeurs débordement de tampon capture / gestion de toutes les exceptions sélectionner des normes de développement sécuritaire en fonction des langages choisit identifier les attaques possibles (arbre d’attaque) former les développeurs

33 Phase : 5. Conception Une bonne pratique du génie logiciel est cruciale à la construction d’un logiciel et d’un système d’information sécuritaire. Design en fonction de la sécurité architecture détaillée diagrammes d’interaction (flux de données) définition des couches (ex: couche de persistance) identification des spécifications techniques du système validation de ces spécifications avec l’équipe du support ajustement, préparation et mise en place des environnements et des plans de tests Phase : 5. Conception Une bonne pratique du génie logiciel est cruciale à la construction d’un logiciel et d’un système d’information sécuritaire. Design en fonction de la sécurité architecture détaillée diagrammes d’interaction (flux de données) définition des couches (ex: couche de persistance) Identifier les modules critiques qui devront être vérifiés (Librairies, paquetages  classes, méthodes, procédures stockées, etc.) identification des spécifications technique du système validation de ces spécifications avec l’équipe du support ajustement, préparation et mise en place des l’environnements et des plans de tests Le responsable de la sécurité doit identifier : comment les données transiteront entre les composantes (entrée et sortie) tous les utilisateurs, rôles et droits qui seront explicitement définis ou implicitement inclus dans le design les relations de confiance entre chaque composante des idées de solutions sécuritaire, applicables pour les problèmes connus

34 Phase : 6. Réalisation Développement du système
écrire le code en fonction des spécifications utiliser les « Security Design Patterns » lorsque disponibles implémenter la sécurité à l’intérieur du code réaliser les tests unitaires qui incluent des tests de sécurité réaliser les tests de sécurité et de PR* réaliser les tests d’intégration Phase : 6. Réalisation Développement du système écrire le code en fonction des spécifications utiliser les « Security Design Patterns » lorsque disponibles implémenter la sécurité à l’intérieur du code réaliser les tests unitaires qui incluent des tests de sécurité réaliser les tests de sécurité et de PR* réaliser les tests d’intégration Le responsable de la sécurité doit pouvoir : participer au développement s’il en a les capacités utiliser la phase de révision de code, pour jeter un coup d’œil sur de possibles bogues de sécurité comprendre le code assez bien pour être capable de le lire et de comprendre les problèmes de sécurité de manière à les communiquer aux développeurs documenter tout ce qui est pertinent au niveau de la sécurité du code

35 Phase : 7. Transition Deux types d’approches complémentaires :
1. L’assurance opérationnelle (validation des fonctionnalités du système) l’architecture du système, les fonctionnalités prévues, l’intégrité du système, l’analyse des canaux cachés, la relève automatique, etc. 2. L’assurance du processus (Validation du cadre de développement et de maintenance du système) sensibilisation et formation des administrateurs et utilisateurs, tests de sécurité, spécification et vérification de l’architecture des composantes du système, gestion de la configuration, distribution sécuritaire des composantes du système Tests de sécurité : tests de « crash », d’interfaces, de relève, de pénétration, etc. Deux types d’approche complémentaires : 1. L’assurance opérationnelle (validation des fonctionnalités du système) On se concentre sur les parties opérationnelles du système, par exemple : l’architecture du système, les fonctionnalités prévues, l’intégrité du système, l’analyse des canaux cachés la relève automatique 2. L’assurance du processus (Validation du cadre de développement et de maintenance du système) Focus sur les processus entourant la réalisation du système, par exemple : mise en œuvre restreinte sensibilisation et formation des administrateurs et utilisateurs tests de sécurité spécification et vérification de l’architecture des composantes du système gestion de la configuration la gestion sécuritaire de la salle des serveurs distribution sécuritaire des composantes du système Tests de sécurité Doivent être réalisés pour chaque type de tests tests unitaires, fonctionnels, de « crash », d’intégration, système, de communication, d’installation, de conformité, de certification, d’accréditation, à l’intérieur de l’environnement cible. Exemples : Tests de « crash » : fermer brutalement le serveur et vérifier le statut des données du système. Tests d’interfaces : utiliser des outils automatiques permettant d’exécuter rapidement les attaques les plus connues. Tests de relève, etc.

36 Phase : 8. Déploiement Installation du système en production ou mise en œuvre d’une version rédiger et MAJ les documents de configuration valider et MAJ le plan de continuité et les plans de relève rédiger les manuels des utilisateurs rédiger les manuels des administrateurs ajuster les procédures et politiques organisationnelles impactées par la mise en ligne du système et informer les personnes touchées par ces changements procéder aux tests d’acceptation au niveau des principales fonctionnalités globales

37 Phase : 9. Production Opération et maintenance
maintenir le système au niveau de confiance attendu appliquer les bonnes pratiques en gestion des identités et de configuration réaliser périodiquement des audits et des tests internes de sécurité Contrôle des changements Posséder un bon processus de gestion des changements sécuritaires doivent être réalisés selon la même méthodologie de développement doivent respecter la politique de sécurité doivent être réalisés à travers des librairies contrôlées (sécuritaires) re-certifier le système à la suite de tout changement, etc. Phase : 9. Production Opération et maintenance Maintenir le système au niveau de confiance attendu re-certifier le système à la suite de tout changement réaliser des audits et tests de sécurité périodiquement Contrôle des changements Sans un bon processus de gestion des changements, un projet peut être sans fin on risque de perdre la trace des changements (qui a fait quoi, et quand) le développement de nouvelles fonctionnalités du système doit être centralisé applications gestion des sources gestion des anomalies (bugs) les changements doivent respecter la politique de sécurité les changements apportés par les développeurs doivent être réalisés à travers des librairies contrôlées (sécuritaires)

38 Phase : 10. Mise à la retraite
Archivage pourquoi archiver les données? en réponse aux contraintes imposées par le contexte d’affaires ou par le contexte juridique implications légales assurer leur disponibilité, garantir leur intégrité et leur confidentialité durant la période requise plusieurs scénarios possibles problématiques ressources partagées, informations réparties, sécurité applicative, etc. Phase : 10. Mise à la retraite Archivage Pourquoi archiver les données? en réponse aux contraintes imposées par le contexte d’affaire ou par le contexte juridique implications légales Actions possibles : retirer le système déplacer et archiver les données utilisées par le système assurer leurs disponibilité, garantir leur intégrité et leur confidentialité, etc. Problématique : bases de données partagées ressources et composantes partagées ex. : dll sous Windows gestion des droits d’accès

39 Phase : 11. Élimination Mise au rebut
disposer judicieusement des archives détruire les données qui étaient utilisées par le système effacement sécuritaire, destruction physique des disques, etc.

40

41 Processus de la sécurité des applications
Étape 1: Mettre en place le processus de sécurité des applications Web

42 Arrimage du modèle générique à votre processus de développement Web
Phases de réalisation et cycle de vie d’un système Web Diachroniquement : un processus linéaire à l’intérieur d’un cycle récurrent Synchroniquement : un objet complexe

43

44 Définitions des principaux intervenants
Chef de projet Son rôle : s’assure que la sécurité ne sera pas sacrifiée au bénéfice de la date de livraison ou du coût, sans une approbation du détenteur s’assure que les activités concernant la sécurisation du système sont incluses dans l’estimation du projet Doit posséder : une bonne connaissance de la gestion de projet de développement de système une bonne compréhension de l’importance de la sécurité informatique pour l’atteinte du niveau de confiance ciblé par le projet Doit livrer à une date cible et à l’intérieur des coûts estimés un système devant passer les tests d’acceptation qui incluent les tests de sécurité.

45 Définitions des principaux intervenants
Responsable de la sécurité Son rôle : intégrer les préoccupations de sécurité à la méthodologie de génie logiciel en place identifier le risque représenter la « Sécurité » à chaque phase de la méthodologie identifier le contexte d’utilisation d’une application ou d’un système d’information établir le processus permettant d’analyser les besoins de sécurité de définir les besoins de sécurité vs le contexte d’implémenter des solutions Doit posséder : une profonde connaissance du développement de logiciel une bonne connaissance de la sécurité informationnelle Est, malheureusement, généralement perçu comme un obstacle au développement...

46 Définitions des principaux intervenants
Architectes, analystes, programmeurs, testeurs, etc. Toutes les personnes impliquées dans le développement d’un système doivent avoir conscience des préoccupations de sécurité pouvant être atténuées à leur niveau d’intervention. Chacune d’elle doit posséder : une bonne connaissance du développement de logiciel, une bonne connaissance du contexte et des limites de son niveau d’intervention, une bonne connaissance des risques et des contraintes inhérents au contexte de fonctionnement des composants qui le concernent, une bonne connaissance des bonnes pratiques et des mesures de sécurité pouvant être utilisées à son niveau d’intervention.

47

48 Conclusions L’introduction d’un système peut avoir un impact sur les quatre secteurs permettant la gestion de la sécurité informationnelle d’une organisation. Les préoccupations de sécurité informationnelle peuvent être abordées dans toutes les phases du cycle de vie du système, lorsque le retour sur l’investissement le justifie. Sensibiliser le détenteur à identifier : le risque et l’impact d’un incident, les rôles, les responsabilités et les permissions des divers intervenants sur la ressource, les informations critiques traitées ou conservées par la ressource. Identifier un détenteur et un responsable de la sécurité pour le projet Les préoccupations de sécurité informationnelle peuvent être abordées à toutes les phases du cycle de vie d’un système, lorsque le retour sur l’investissement le justifie. Sensibiliser le détenteur sur le risque et à l’impact d’un incident! Importance de sensibiliser, de former et de donner les bons outils à l’ensemble des intervenants concernés. Administrateurs, gestionnaires, utilisateurs, techniciens, analystes, développeurs, etc. G T S RI V

49 Conclusions Importance de sensibiliser, de former et de donner les bons outils à l’ensemble des intervenants concernés. Administrateurs, gestionnaires, détenteur, utilisateurs, techniciens, développeurs, testeurs, pilotes, etc. Un système qui n’a pas été développé avec la sécurité en tête risque de ne jamais être sécuritaire… Les préoccupations de sécurité informationnelle peuvent être abordées à toutes les phases du cycle de vie d’un système, lorsque le retour sur l’investissement le justifie. Sensibiliser le détenteur sur le risque et à l’impact d’un incident! Importance de sensibiliser, de former et de donner les bons outils à l’ensemble des intervenants concernés. Administrateurs, gestionnaires, utilisateurs, techniciens, analystes, développeurs, etc. G T S RI V

50 Merci de votre attention.
Sécurité et méthodologie dans le développement de système Merci de votre attention. Des questions? Luc Poulin M.Sc CISSP-ISSMP CISA ift.a Conseiller senior Chef de la sécurité du CRIM Courriel : Cette présentation a été réalisée avec la participation de M. Bruno Guay, conseiller senior en sécurité des TI.