2015-04-28 Bruno Guay Sécurité des projets informatiques

Colloque en gestion de projet 2015
1
Gérer la sécurité dans les projets informatiques
Bruno Guay
Conseiller senior
Nurun

2
Cette présentation sera disponible sur le site internet
du PMI Lévis-Québec à compter du 5 mai 2015

3
• Bruno Guay, conseiller expert en sécurité
de l'information, Nurun
• Co rédacteur de la Norme ISO/CEI 27034 –
« Sécurité des applications »
• Luc Poulin, président, Cogentas
• Co rédacteur de la Norme ISO/CEI 27034 –
« Sécurité des applications »

4
Plan
• La sécurité des applications
– Pourquoi est-ce important?
– Pourquoi est-ce difficile?
– Besoins
• La norme ISO 27034
– Concepts
– Processus
– Intérêt dans l’industrie

5
La sécurité des
applications – pourquoi
est-ce important?

6
Pourquoi est-ce important?
• Nos applications sont attaquées de façon
croissante.
• Nos applications sont vulnérables aux
attaques.

7
• Cas récent du magasin Target aux États-Unis,
qui s’est fait voler 110 millions
d’enregistrements de cartes de crédit.
• Cela a entraîné pour Target
– des pertes financières considérables;
– une perte de réputation considérable;
– la démission forcée de son PDG et de son CIO.

8

9
• 78% des applications Web présentent des
vulnérabilités facilement exploitables.
• Les vulnérabilités les plus exploitées sont bien
connues, ce sont les mêmes depuis 2007.
• C’est une de ces vulnérabilités qui a été
exploitée contre Target.

10
• Jusqu’à maintenant on a surtout protégé
l’infrastructure informatique, la quincaillerie.
• Or le profil des attaques a changé.
• Les pirates le disent : il est plus facile et plus
rentable d’attaquer les applications que
l’infrastructure.
• Maintenant plus de 75% des attaques sont au
niveau de l'application.

11
Citoyen
Analyste
Enquêteur
Application
web
Données
SQ
GRC
DPCP
Pirate
2004

12
Citoyen
Analyste
Enquêteur
Application
web
Données
SQ
GRC
DPCP
Pirate
2014

13
• Depuis 3 années consécutives, les applications
arrivent en tête des vulnérabilités de sécurité
• 90% des failles de sécurité viennent de
vulnérabilités d'application
• INFOSECURITY PROFESSIONAL, numéro 21 - Executive
letter from the desk of the ISC2 Executive Director
+

14
• 90% des sites sont vulnérables aux attaques
d'application (Watchfire)
• 78% des applications Web présentent des
vulnérabilités facilement exploitables (Symantec)
• 80% des entreprises auraient connu un incident
de sécurité relié aux applications entre 2008 et
2010 (Gartner)
• Injection XSS et SQL sont les vulnérabilités
OWASP #1 et #2 depuis 2007 (Mitre)
+

15
La sécurité des
applications – pourquoi
est-ce difficile?

16
Pourquoi est-ce difficile?
• La sécurité est mal comprise par les équipes
de projets.
– Est l’objet de mythes répandus :
• la sécurité c’est technologique;
• la sécurité c’est opérationnel.
– Non perçue comme un besoin d’affaires.
– Perçue comme cause de dépassements de coût et
d’échéancier.
– Perçue comme une couche de peinture qu’on
applique au produit final.

17
• On entend souvent : « L’important est que
l’application fonctionne. Ensuite on verra pour
la sécurité »
• Remplaçons « l’application » par « l’avion »…
• « L’important est que l’avion fonctionne.
Ensuite on verra pour la sécurité »

18
• La sécurité est mal intégrée aux projets
d’applications :
– peu intégrée dans les méthodologies de
développement;
– peu intégrée dans les processus des bureaux de
projets;
– les architectes et spécialistes de sécurité sont peu
intégrés aux équipes de projets.
• Rarement intégrés dès le début

19
• L’environnement technologique est de plus en
plus complexe.
• Le contexte d’utilisation d’une application peut
changer au fil du temps.
• Par exemple, on migre maintenant des
applications de l’ordinateur central aux
téléphones intelligents – ceci change
complètement l’exposition aux menaces.
• Pourtant, l’organisation doit toujours se
conformer aux mêmes exigences d’affaires et
légales.

20
• Difficile pour les clients :
– Peu de contrôle sur les applications acquises, gérées
par des tierces parties ou hébergées;
• Sont-elles vulnérables?
• Sont-elles bien installées et configurées?
• Sont-elles bien gérées?
– Peu d’exigences de sécurité dans les appels d’offres;
• Absence de critères vérifiables
• Absence de preuve de conformité
– Peu de clauses de sécurité dans les contrats.
• Peu de droit de regard pour le client
• On dépend du bon vouloir du fournisseur
+

21
• Difficile pour les fournisseurs :
– Peu d’activités de sécurité dans les méthos de
développement;
– Peu de contrôles de sécurité (bonnes pratiques);
– Peu de tests de sécurité;
– Absence de critères formels et vérifiables;
– Absence d’un processus répétable pour appliquer
la sécurité dans un projet;
– La sécurité d’une application dépend de la
compétence de chaque équipe.
+

22
• Difficile pour les auditeurs :
– Difficulté à définir l’application et à délimiter la portée de
l’évaluation;
• Quels systèmes, quels progiciels?
• Logiciel, processus ou infrastructure?
• Frontière floue entre l’application et l’infrastructure
– Absence de processus d’évaluation adéquat;
• Absence d’exigences standard
• Absence de processus d’évaluation standard
• Absence de méthodologie d’analyse de risque pour les applications
– Peu de similitudes entre les mandats de vérification;
• Difficile d’appliquer les mêmes critères
• Improvisation à chaque intervention
• Efficacité et efficience réduite
+

23
Besoins

24
Besoins
• L’objectif est d’améliorer la sécurité de nos
applications
– Être en meilleur contrôle de la sécurité
– Être en mesure de le démontrer
– Augmenter l’efficacité
– Augmenter l’efficience

25
Besoins
• Plus précisément :
– Appliquer des contrôles de sécurité qui réduisent
adéquatement le risque
– Gérer avec efficience ces contrôles de sécurité
dans tout le cycle de vie de l’application
– Démontrer que ces contrôles restent adéquats

26
Besoins
• Concrètement, il faut répondre à la question
de Bertrand, chargé de projet :
“On m’a dit : Bertrand, pour ce projet, il te
faut la sécurité du Pentagone.
Moi je veux bien, mais ça veut dire quoi,
ça? Et je fais quoi, là?”

27
Besoins
• Le chargé de projet a besoin de connaître les
exigences de sécurité dès le début du projet
activités de sécurité pour planifier les
ressources
– Qui fait quoi, quand, comment, à quel effort

28
Besoins
activités de vérification de sécurité pour valider
les livrables
– Qui fait quoi, quand, comment, à quel effort
• Le chargé de projet a besoin d’un tableau de bord
de sécurité
– Activités planifiées, en cours, complétées, vérifiées
– Efforts réalisés, dépassements
– Problèmes et feedback à retourner à l’organisation

29
Besoins
• Réponse à la question de Bertrand :
On ajoute des activités de sécurité et de
vérification aux processus existants

30
La Norme
ISO 27034

31
La Norme ISO 27034
• 27034-1: Survol et concepts (publiée)
• 27034-2: Cadre normatif de l’organisation
• 27034-3: Processus de gestion de la sécurité d’une
application
• 27034-4: Vérification de la sécurité d’une application
• 27034-5: Protocoles et structures de données
• 27034-6: Exemples
+

32
La Norme ISO 27034
• Cette nouvelle norme propose un modèle pour faciliter
l’intégration de la sécurité dans le cycle de vie des
applications :
– concepts, principes, cadres;
– composants et processus.
• Elle s’applique autant au développement interne qu’à
l’acquisition ou l’impartition.
• Elle propose des lignes directrices pour les propres
processus et méthodologies de l’organisation.
• Elle ne propose pas de contrôles ou de règles de
développement.

33
La Norme ISO 27034
• La Norme énonce des principes :
– La sécurité est un besoin d’affaires.
– La sécurité d’une application dépend de son
contexte d’utilisation.
– Il faut investir les ressources appropriées pour
sécuriser une application – ni plus ni moins.
– La sécurité d’une application doit pouvoir être
prouvée.

34
Une nouvelle vue sur la sécurité
ApplicationOrganisation

35
Concepts

36
Cadre normatif de l’organisation

37
Contrôle de sécurité applicative
CSA
Activité de vérification
(qui, quand, quoi, comment,coût)
Activité de sécurité
(qui, quand, quoi, comment,coût)
Exigence de sécurité
(pourquoi)

38
• C’est une mesure de réduction de risque
• Créé, approuvé et maintenu par l’organisation
• Utilisé par les équipes de projet et d’opération
• Utilisé par les équipes d’assurance-qualité et
d’audit
• Peut servir pour le développement interne ou
comme critère d’acceptation / homologation
• Vérifiable en tout temps

39
• Chaque contrôle de sécurité comprend :
– le niveau de confiance applicable;
– une exigence de sécurité en rapport avec :
• un risque;
• une spécification fonctionnelle; ou
• un élément de contexte d’affaires, régulatoire, technologique.
• Une activité de sécurité – la description détaillée de la
mesure de réduction du risque.
• Une activité de vérification qui permettra de prouver
que la mesure de réduction du risque a été appliquée
avec succès.
+

40
Le niveau de confiance
• La norme simplifie l’architecture de sécurité avec
le concept de niveau de confiance.
• C’est un ensemble prédéfini et réutilisable de
contrôles de sécurité.
• C’est un indice de tolérance au risque.
• On distingue :
– le niveau de confiance ciblé, décidé par le propriétaire
de l’application suite à l’analyse de risque;
– le niveau de confiance réel, mesuré par une
vérification, un audit.

41
Le niveau de confiance
• C’est le plan d’action de sécurité pour
l’application.
• On fait déjà : analyse de risque et plan d’action,
mais c’est improvisé chaque fois et c’est toujours
à recommencer.
• La Norme standardise le processus dans
l’organisation.
• Suite à l’analyse de risque, on choisit un plan
d’action pré approuvé et éprouvé.
• Gain d’efficacité et d’efficience majeur.

42
La banque de contrôles de sécurité applicative
Double-clic to edit
▶ Liste de tous les CSA de l’organisation
...0
Librarie des CSA de l’organisation
1 32 9 10
Niveaux de confiance d’application
utilisés par l’organisation
Banque des CSA de l’organisation

43
La banque de contrôles de sécurité
applicative
• Similaire à un recueil de bonnes pratiques.
• Adaptée aux besoins spécifiques de l’organisation.
• Adaptée au contexte d’affaires, légal et technologique.
• Alimentée par les normes et standards, les bonnes
pratiques du marché, l’expérience de l’organisation.
• Gérée et approuvée par l’organisation.
• Elle contient les contrôles disponibles pour chaque
spécification fonctionnelle et chaque degré de
confiance désiré.
+

44
Modèle de cycle de vie pour la sécurité
d’une application

45
Processus

46
Processus
• La Norme repose sur des processus que
l’organisation doit définir ou arrimer avec ses
processus existants.
• Deux niveaux de processus :
– Organisationnel : gestion du Cadre normatif
organisationnel;
– Projet : utilisation du Cadre normatif
organisationnel pour gérer la sécurité d’une
application.

47
Processus
Processus
de gestion
Cadre Normatif
de l’Organisation
Cadre Normatif
de l’Application 1
Processus
de gestion
Cadre Normatif
de l’Application 2
Processus
de gestion
Niveau du
projet
Niveau de
l’organisation

48
Processus de gestion de la sécurité d’une application
Application Normative
Framework
Évaluer les risques de
sécurité amenés
par l’application
Identifie
les contextes et les
spécifications de l’application
requis pour
4
3
Créer et maintenir le
cadre normatif de
l’application
Produit
5
Vérifer la sécurité de
l’application
Identifier les besoins et
l’environnement de
l’application
Produit les
artéfacts du projet
et le CNA utilisés pour
2
Produit
Identifie les
correctifs de sécurité
utilisés pour
Produit les
CSA utilisés pour
1
Détermine
Est requis
pour
Est utilisé
pour
Cadre normatif de
l’application
Réaliser et
utiliser l’application
Niveau de confiance
réel de l’application
Niveau de confiance
cible pour l’application
Cadre normatif
de
l’organisation

49
sécurité amenés
par l’application
Identifie
requis pour
4
3
cadre normatif de
l’application
Produit
5
l’application
l’application
Produit les
2
Produit
Identifie les
utilisés pour
Produit les
CSA utilisés pour
1
Détermine
Est requis
pour
Est utilisé
pour
Cadre normatif de
l’application
Réaliser et
Niveau de confiance
Niveau de confiance
Application Normative
Framework
Cadre normatif
de
l’organisation
On détermine les éléments qui ont un impact sur la
sécurité de l’application:
• spécifications
• acteurs
• information
• contextes d’affaire, régulatoire, technologique

50
sécurité amenés
par l’application
Identifie
requis pour
4
3
cadre normatif de
l’application
Produit
5
l’application
l’application
Produit les
2
Produit
Identifie les
utilisés pour
Produit les
CSA utilisés pour
1
Détermine
Est requis
pour
Est utilisé
pour
Cadre normatif de
l’application
Réaliser et
Niveau de confiance
Niveau de confiance
Le propriétaire de l’application
détermine le niveau de
confiance ciblé
Cadre normatif
de
l’organisation
On identifie, analyse et
évalue les risques
On en déduit les exigences de
sécurité

51
sécurité amenés
par l’application
Identifie
requis pour
4
3
cadre normatif de
l’application
Produit
5
l’application
l’application
Produit les
2
Produit
Identifie les
utilisés pour
Produit les
CSA utilisés pour
1
Détermine
Est requis
pour
Est utilisé
pour
Cadre normatif de
l’application
Réaliser et
Niveau de confiance
Niveau de confiance
On extrait du CNO les contrôles pertinents pour
réduire le risque de l’application en fonction
des spécifications trouvées en 1 et du Niveau
de confiance ciblé choisi en 2
Cela donne un extrait du CNO qu’on
appelle CNA: le Cadre normatif de
l’application
C’est un dépôt permanent qui contient
toute l’information détaillée relative à
la sécurité de cette application
Cadre normatif
de
l’organisation

52
Contexte
technologique relié
à l’environnement
de l’application
Contexte
d’affaires relié à
l’environnement
de l’application
Contexte
juridique relié à
l’environnement
de l’application
Spécifications
de l’application
Rôles, responsabilités
et qualifications des
acteurs impliqués par
l’application
Processus reliés
à la sécurité de l’application
CSA sélectionnés pour chacune
des phases de l’application
Cycle de vie de l’application
Cadre normatif de l’application

53
Contexte
technologique relié
à l’environnement
de l’application
Contexte
d’affaires relié à
l’environnement
de l’application
Contexte
juridique relié à
l’environnement
de l’application
Spécifications
de l’application
Rôles, responsabilités
et qualifications des
acteurs impliqués par
l’application
Processus reliés
à la sécurité de l’application
CSA sélectionnés pour chacune
des phases de l’application
Cycle de vie de l’application
Cadre normatif de l’application
On ajoute des activités de sécurité et de
vérification aux processus existants

54
sécurité amenés
par l’application
Identifie
requis pour
4
3
cadre normatif de
l’application
Produit
5
l’application
l’application
Produit les
2
Produit
Identifie les
utilisés pour
Produit les
CSA utilisés pour
1
Détermine
Est requis
pour
Est utilisé
pour
Cadre normatif de
l’application
Réaliser et
Niveau de confiance
Niveau de confiance
Cadre normatif
de
l’organisation
vérification de tous les contrôles
On utilise les contrôles prescrits par le
CNA pendant tout le cycle de vie de
l’application
• acquisition ou développement
• opération, maintenance, mise à la
retraite
On réalise toutes les activités de sécurité
de tous les contrôles
On réalise toutes les activités de
vérification de tous les contrôles

55
Les contrôles sur l’application livrée
Citoyen
Analyste
Enquêteur
Application
web
Données
SQ
GRC
DPCP
CSA
CSA
CSA
CSA
CSA
CSA
CSA
CSA
CSA
CSA
CSA
CSA
CSA
CSA

56
sécurité amenés
par l’application
Identifie
requis pour
4
3
cadre normatif de
l’application
Produit
5
l’application
l’application
Produit les
2
Produit
Identifie les
utilisés pour
Produit les
CSA utilisés pour
1
Détermine
Est requis
pour
Est utilisé
pour
Cadre normatif de
l’application
Réaliser et
Niveau de confiance
Niveau de confiance
Cadre normatif
de
l’organisation
On vérifie le résultat (la preuve) de toutes
les activités de vérification de tous les
contrôles
Le résultat est le Niveau de confiance réel

57
• L’audit peut être réalisé en tout temps dans le cycle de vie de l’application
• Il peut être réalisé par des auditeurs internes ou externes
• Il devrait être réalisé au moment d’un point de décision : mise en
production, acceptation, homologation, etc.
• Il consiste simplement à vérifier que tous les contrôles ont été vérifiés
avec succès
• Si un contrôle n’a pas été vérifié avec succès, on n’atteint pas le Niveau de
confiance ciblé
• Si le Niveau de confiance réel = Niveau de confiance ciblé, l’organisation
peut déclarer que l’application est sécuritaire
• … jusqu’au prochain audit
• Le Niveau de confiance réel représente le risque résiduel au moment où
l’audit est réalisé
• Le Niveau de confiance réel est basé sur des preuves
+Processus de gestion de la sécurité d’une application

58
Intérêt manifesté dans
l’industrie

59
Intérêt manifesté dans l’industrie
• Collaborateurs enthousiastes à la rédaction et
l’adoption par ISO/IEC :
– Microsoft
– Intel
– Cisco
– Boeing
– OWASP
– Représentants d’environ 15 pays membres
– Experts en sécurité et en génie logiciel.
• 27 pays membres votants sur 28 ont voté pour la
publication (96%) en novembre 2011.

60
• Des organismes sont actuellement en projet
d’implantation de ISO 27034. Par exemple, au
Canada :
– Élections Canada
– Une institution financière majeure
– Un fournisseur d’applications du domaine du
transport
– Un fournisseur d’applications du domaine de la santé
• Des organismes prévoient un projet
d’implantation de ISO 27034
– Deux banques majeures canadiennes

61
One way to counteract this lack of
security is to make sure that when
you begin developing, you take into
account potential security issues by
following a “relatively new security
standard for software development,
ISO 27034.”
Howard Schmidt, former CyberSecurity
advisor to US President Obama
Tech bigwigs Microsoft, Adobe, and
Cisco are all supporting this new
standard, which emphasizes integrating
security into a product’s early
development stages rather than
introducing security when issues
eventually begin to sprout.

62 Double-clic to edit

63
Conclusion
• La Norme ISO 27034 facilite la gestion de la sécurité
dans un projet d’application.
• Elle apporte un gain appréciable d’efficacité et
d’efficience.
• Elle permet une meilleure planification des activités et
des ressources du projet.
• Elle permet de réduire les risques du projet:
– dépassement de budget;
– dépassement de durée.
• Elle permet de valider que l’application livrée répond
aux exigences de sécurité.

64
Questions?

2015-04-28 Bruno Guay Sécurité des projets informatiques

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (19)

Similaire à 2015-04-28 Bruno Guay Sécurité des projets informatiques

Similaire à 2015-04-28 Bruno Guay Sécurité des projets informatiques (20)

Plus de PMI Lévis-Québec

Plus de PMI Lévis-Québec (20)

Dernier

Dernier (20)

2015-04-28 Bruno Guay Sécurité des projets informatiques