Tous droits réservés © 2005 CRIM Luc Poulin M.Sc CISSP-ISSMP CISA ift.a Conseiller senior Chef de la sécurité du CRIM Intégrer la sécurité dans le cycle

Tous droits réservés © 2005 CRIM

Luc Poulin M.Sc CISSP-ISSMP CISA ift.aConseiller seniorChef de la sécurité du CRIM

Intégrer la sécurité dans le cycle de vie d’un système

La sécurité des applications18 octobre 2007

Web éducation

2Tous droits réservés © 2006 CRIM

Plan de la présentationPlan de la présentationPlan de la présentationPlan de la présentation Introduction et mise en contexte Méthodologie de développement sécuritaire Que fait-on à chaque phase

(Comment le faire, quoi vérifier…)

Comment intégrer cette approche à notre processus de développement Web…

Rôles des principaux intervenants Conclusion

– Luc Poulin

Intégrer la sécurité dans le cycle de vie d’un systèmeIntégrer la sécurité dans le cycle de vie d’un système

1. Préparation 6. Réalisation2. Évaluation 7. Transition3. Définition 8. Déploiement4. Spécification 9. Production5. Conception 10. Mise à la retraite

11. Élimination

3Tous droits réservés © 2006 CRIM – Luc Poulin


Problématique à l’intégration de la sécurité Problématique à l’intégration de la sécurité dans le cycle de vie d’un systèmedans le cycle de vie d’un systèmeProblématique à l’intégration de la sécurité Problématique à l’intégration de la sécurité dans le cycle de vie d’un systèmedans 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èmeet 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.



Un des défis, savoir gérer des buts divergentsUn des défis, savoir gérer des buts divergentsUn des défis, savoir gérer des buts divergentsUn des défis, savoir gérer des buts divergents

Buts de la sécurité Buts de la sécurité dans les applicationsdans les applications

• PréventionPrévention• TraçabilitéTraçabilité• SurveillanceSurveillance• ConfidentialitéConfidentialité• Sécurité multi-niveauxSécurité multi-niveaux• AuthentificationAuthentification• IntégritéIntégrité• Etc.Etc.

Buts des projets de Buts des projets de développement développement d’applicationsd’applications

• Fonctionnalité• Convivialité• Efficacité• Développement rapide• Simplicité• Faible coût



DéfinitionsDéfinitionsDéfinitionsDéfinitions Application d’affaire

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.



*..*

1..*

Processus d’affaire

Besoin d’affaire1..*

M / O

Contexte juridique1..*

Critique

Critique

1..*

Contexte d’affaire

Actif informationnel

1..*

Contexte Technologique

La sécurité de l’information et l’organisationLa sécurité de l’information et l’organisationLa sécurité de l’information et l’organisationLa sécurité de l’information et l’organisation

1..*Matériel

Système

Applications

Données

Critique

Personnes

Processus

Technologies

Informations

Ressource informationnelleCrit

ique


Intégrer la sécurité dans le cycle de vie d’un systèmeIntégrer la sécurité dans le cycle de vie d’un systèmeUne vision globale des domaines de Une vision globale des domaines de connaissanceconnaissanceUne vision globale des domaines de Une vision globale des domaines de connaissanceconnaissance

Gestion de la sécurité(Gouvernance)

Vérification et contrôle(Conformité)

RessourcesInformationnelles

critiques

Systèmes(Développement

et évolution)

Technologie

(Acquisition,

maintenance et

contingence)



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é.

Que devons nous faire pour développer Que devons nous faire pour développer un système en lequel nous aurons confiance? un système en lequel nous aurons confiance? Que devons nous faire pour développer Que devons nous faire pour développer un système en lequel nous aurons confiance? un système en lequel nous aurons confiance?



Objectifs de la sécurité des applicationsObjectifs de la sécurité des applications – besoins des utilisateurs… – besoins des utilisateurs…Objectifs de la sécurité des applicationsObjectifs de la sécurité des applications – besoins des utilisateurs… – 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é.





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 ?





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 ?





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 !


Intégrer la sécurité dans le cycle de vie d’un systèmeIntégrer la sécurité dans le cycle de vie d’un systèmeLes trois piliers de la sécurité, Les trois piliers de la sécurité, par ordre d’importance, en vue de protéger les par ordre d’importance, en vue de protéger les informationsinformations

Les trois piliers de la sécurité, Les trois piliers de la sécurité, par ordre d’importance, en vue de protéger les par ordre d’importance, en vue de protéger les informationsinformations

1. Les personnes

2. Les processus

3. La technologie



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.

Les trois piliers de la sécurité, par ordre Les trois piliers de la sécurité, par ordre d’importance, d’importance, en vue de protéger les informationsen 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.





3. La technologieOffre 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.








– Luc Poulin



11. Élimination



Pré requis essentiels à la sécurité logiciellePré requis essentiels à la sécurité logiciellePré requis essentiels à la sécurité logiciellePré 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



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

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

Personnes (équipe de réalisation)

Projet (acquisition, impartition,

développement, évolution, etc.)

Cadre normatif de l’application

(processus)

Product (ressource informationelle :

système, application, composant)

Participent

Supporte la réalisation

Génère

AutomatiseTechnologie (outils matériels

et logiciels)

Personnes (utilisateurs,

administrateurs, techniciens, pilotes, etc.)

Installent, utilisent,

maintiennent

Cadre normatif de l’organisation

(lois, normes, politiques, et bonnes pratiques

reconnues par l’organisation)

Identifie

Encadre

Personnes (équipe de vérification)

Vérifie, contrôle

Valide, vérifie,

contrôle

Vérifie, contrôle,

conseille

Vérifie, Contrôle

MSAMSAMSAMSAMSA



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


(processus)

MSA Utilisent

Fournit

Personnes (équipe de réalisation)

Projet (acquisition, impartition,

développement, évolution, etc.)

Product (ressource informationelle :

système, application, composant)

Participent

Supporte la réalisation

Génère

Personnes (utilisateurs,

administrateurs, techniciens, pilotes, etc.)

Installent, utilisent,

maintiennent

Identifie

Personnes (équipe de vérification)

Vérifie, contrôle

Vérifie, contrôle,

conseille

Vérifie, Contrôle



ASM ASM

ASM ASM

ASM

ASM

ASM

ASM

ASM

ASM

ASM

ASM

ASM

ASM

ASM

La mesure de sécurité de l’application (MSA)La mesure de sécurité de l’application (MSA)La mesure de sécurité de l’application (MSA)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.)



La mesure de sécurité de l’application (MSA)La mesure de sécurité de l’application (MSA)La mesure de sécurité de l’application (MSA)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, complexité, qualification requise par les acteurs, coût de l’activité de contrôle, précise si une vérification périodique est requise, etc..



Liste des MSA de Liste des MSA de l’organisationl’organisationpour tous pour tous les niveaux de les niveaux de confiancesconfiances

Liste des MSA de Liste des MSA de l’organisationl’organisationpour tous pour tous les niveaux de les niveaux de confiancesconfiances

0

Liste des MSA de l’organisation

1 32 9...

10

MSA

MSA

MSA

MSA

MSA

MSA

MSA

MSA

MSA

MSA

MSA

MSA MSA

MSA

MSA

MSA

MSA

MSA

MSA

MSA MSA

MSA MSAMSA

MSA

MSA MSA

MSA

MSA

MSA

MSA

MSA

MSA

MSA

MSA MSAMSA

MSA



Besoins opérationnelles,

ententes

Informe, recommandeResponsable de la sécurité dans

le projet

Responsable de la vérification dans le projet

Direction de l’organisation

Identifie

Mandate, autorise

Conseille, valide

Conseille, valide

Équipe de réalisation

Personnels externes au

projet

Conseillent

Cadre normatif de l’applicaion

Guide

Infrastructure technologique de l’application(Matériel et logiciels nécessaire aux environnements de gestion,

de développement, de tests, d’exécution et d’archivage)

Utilisent

Chef de la sécurité(CSO)

Équipe des tests

Équipe de développement

Architecture Team

(architectes, analystes, etc.)

Équipe de développement

Représentantde l’équipe

technologique

Chef de projet

Équipe organisationnelle

Gère

Détenteur de l’application

Informe

Équipe de vérification

Est supporté

par, informe

Conseille, Informe

Équipe technologique

Équipe de compilation et d’intégration Est supporté par,

informe

Représentants des utilisateurs

Identifient les besoins,

valident

Identifient les besoins,

valident

Verifie, contrôle

Identifie

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






– Luc Poulin



11. Élimination



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

Cad

re no

rmatif

de l’o

rgan

isation

Development and methodology Team

Application Technical Management Team


Technical Support and Maintenance Team (ITIL)

Users

Organisation Management Team Organisation Management Team

Internal Audit Team Internal / External Audit Team

Application Security Concerns (All teams including Application and Technical Security team)

Gestion de projet de développement Gestion de l’application / Système

Audits périodiques de l’application / Système(Opération)

Audits périodiques de l’application / Système(Réalisation)

Gestion de l’infrastructure technologique

UtilisationTransition

Préparation

B

Impartission

Développement interne

Acquisition

Cyle de vie générique de la sécurité d’applications

Acteurs


Ex.: Phases de développement vs Ex.: Phases de développement vs technologiquetechnologiqueEx.: Phases de développement vs Ex.: Phases de développement vs technologiquetechnologique

– Luc Poulin


Env. production cible

Env. Tests

Env. Développement

ArchivageEnv

iron

nem

ents

Préparation env. devl

Préparation des env. de tests

Identification des environnements

nécessaires au projet

Ajustement de l’env. de production

Préparation env. d’archivage

1 2 3 4 5 6 7 8 9 10

t

1. Préparation2. Évaluation

3. Définition4. Spécification

5. Conception6. Réalisation7. Transition8. Déploiement9. Production

11. Élimination

10. Mise à la retraite



– Luc Poulin



Env. Tests

Env. Développement

ArchivageEnv

iron

nem

ents







1 2 3 4 5 6 7 8 9 10

t

Validation des spécifications avec l’équipe du support

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



– Luc Poulin



Env. Tests

Env. Développement

ArchivageEnv

iron

nem

ents







1 2 3 4 5 6 7 8 9 10

t


Phase : 2. ÉvaluationInitialisation 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



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

Risques résiduels pour l’organisation à utiliser cette application

Permet d’évaluer

Contexte juridique

Contexte d’affaire

Caractéristiques de l’application

Contexte technologique

Determine

Préoccupations de sécurité concernés pour cette application

Analyse de risque de l’application

Identiie

Approbation du détenteur

Niveau de confiance

ciblé pour cet application



– Luc Poulin



Env. Tests

Env. Développement

ArchivageEnv

iron

nem

ents







1 2 3 4 5 6 7 8 9 10

t


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



– Luc Poulin



Env. Tests

Env. Développement

ArchivageEnv

iron

nem

ents







1 2 3 4 5 6 7 8 9 10

t


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



– Luc Poulin



Env. Tests

Env. Développement

ArchivageEnv

iron

nem

ents







1 2 3 4 5 6 7 8 9 10

t


Phase : 5. ConceptionUne 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



– Luc Poulin



Env. Tests

Env. Développement

ArchivageEnv

iron

nem

ents







1 2 3 4 5 6 7 8 9 10

t


Phase : 6. RéalisationDé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



– Luc Poulin



Env. Tests

Env. Développement

ArchivageEnv

iron

nem

ents







1 2 3 4 5 6 7 8 9 10

t


Phase : 7. TransitionDeux 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.



– Luc Poulin



Env. Tests

Env. Développement

ArchivageEnv

iron

nem

ents







1 2 3 4 5 6 7 8 9 10

t


Phase : 8. DéploiementInstallation 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



– Luc Poulin



Env. Tests

Env. Développement

ArchivageEnv

iron

nem

ents







1 2 3 4 5 6 7 8 9 10

t


Phase : 9. ProductionOpé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.



– Luc Poulin



Env. Tests

Env. Développement

ArchivageEnv

iron

nem

ents







1 2 3 4 5 6 7 8 9 10

t


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.



– Luc Poulin



Env. Tests

Env. Développement

ArchivageEnv

iron

nem

ents







1 2 3 4 5 6 7 8 9 10

t


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.






– Luc Poulin



11. Élimination



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

Cadre normatif de l’organisation

Utilise

Pour créer

Aide a estimer

Qui vont s’appliquer au

System / Software life cycle

Application Security life cycle

Intégrer au

Réutiliser de

Risques résiduels, Coûts,Niveau de confiance cible de l’application

Project

Security activities and controls(ASM)

Étape 5: Cycle de vie de la sécurité de l’application

Étape 2: Cadre normatif du Gouv du Québec

Étape 4: Cadre normatif de l’application

Niveau de confiance cible de

l’application

Verification

Pour identifier

Niveau de confiance

réel de l’application

Étape 3: Gestion du risque de l’application

Étape 6: Vérification de la sécurité de l’application

Rétroaction du projet

Analyse de risque de l’application


Processus de la sécurité des applicationsProcessus de la sécurité des applicationsProcessus de la sécurité des applicationsProcessus de la sécurité des applications


Intégrer la sécurité dans le cycle de vie d’un systèmeIntégrer la sécurité dans le cycle de vie d’un systèmeArrimage du Arrimage du modèle modèle générique à générique à votre processus votre processus de de développement développement WebWeb

Arrimage du Arrimage du modèle modèle générique à générique à votre processus votre processus de de développement développement WebWeb

Cadre norm

atif de l’organisation





Users

Organisation Management Team Organisation Management Team







UtilisationTransition

Préparation

B

Impartission

Développement interne

Acquisition

Cyle de vie générique de la sécurité d’applications

Acteurs

Cadre norm

atif de l’application





Users







Cyle de vie de la sécurité d’une application

Acteurs

Objectifs Planification Réalisation Opération ÉliminationArchivage Évaluation

NavigationGraphismes

Structure

Programmation Hébergement

Alimentationen contenu

NavigationGraphismes

Structure

Programmation Hébergement

Alimentationen contenu

Phases de réalisation et cycle de vie d’un système Web

Diachroniquement : Diachroniquement : un processus linéaire un processus linéaire à l’intérieur d’un cycle à l’intérieur d’un cycle récurrentrécurrent

Synchroniquement : Synchroniquement : un objet complexeun objet complexe






– Luc Poulin



11. Élimination



Définitions des principaux intervenantsDéfinitions des principaux intervenantsDéfinitions des principaux intervenantsDéfinitions des principaux intervenantsChef 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é.



Définitions des principaux intervenantsDéfinitions des principaux intervenantsDéfinitions des principaux intervenantsDéfinitions des principaux intervenantsResponsable 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...



Définitions des principaux intervenantsDéfinitions des principaux intervenantsDéfinitions des principaux intervenantsDéfinitions des principaux intervenantsArchitectes, 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.






– Luc Poulin



11. Élimination



ConclusionsConclusionsConclusionsConclusions

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 T S

G

V

RI



ConclusionsConclusionsConclusionsConclusions

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…

T S

G

V

RI



Merci de votre attention.

Des questions?

Luc Poulin M.Sc CISSP-ISSMP CISA ift.a

Conseiller seniorChef de la sécurité du CRIM

Courriel : [email protected]

Cette présentation a été réalisée avec la participation Cette présentation a été réalisée avec la participation de M. Bruno Guay, conseiller senior en sécurité des TI.de M. Bruno Guay, conseiller senior en sécurité des TI.

Sécurité et méthodologie dans le Sécurité et méthodologie dans le développement de systèmedéveloppement de système

Sécurité et méthodologie dans le Sécurité et méthodologie dans le développement de systèmedéveloppement de système

Documents

Tous droits réservés © 2005 CRIM Luc Poulin M.Sc CISSP-ISSMP CISA ift.a Conseiller senior Chef de la sécurité du CRIM Intégrer la sécurité dans le cycle