La gestion des risques de sécurité applicative des... · Les facteurs de risque • La menace:...
Transcript of La gestion des risques de sécurité applicative des... · Les facteurs de risque • La menace:...
La gestion des risquesde sécurité applicative
Bruno Guay2018-04-26
1
Introduction
• De nos jours, toute entreprise se doit d’être présente sur le Web et dans l’écosystème des appareils mobiles– pour y présenter ou recueillir de l’information– pour y offrir des transactions et des promotions– pour y permettre la discussion et la collaboration
• De façon croissante les fournisseurs cherchent à contrôler à distance les appareils qu’ils fabriquentet en obtenir de la rétroaction (“Internet of Things”)
• Toutes ces fonctions sont offertes par des applications
2
Introduction
• Toutes ces applications sont une cible de choixpour des individus, groupes, organisations ougouvernements mal intentionnés.
• Ils sont attirés par la valeur monétaire, politique ou stratégique de l’informationaccessible par ces applications.
• La gestion des risques de sécurité applicative est une partie importante de la gestion des risques organisationnels.
3
PANORAMA DU RISQUE
4
Les facteurs de risque
• La menace: nos applications sont attaquées de façon continuelle et croissante.
• La motivation: l’information vaut de l’or, c’est l’appât du gain qui motive les attaques.
• La vulnérabilité: nos applications sontvulnérables aux attaques.
• L’impact: pour les victimes la perte financière, le dommage à la réputation, la non-conformité, la responsabilité sont souvent énormes.
5
L’impact
• 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 (292 M$);– une perte de réputation considérable;– la démission forcée de son PDG et de son CIO;– l’obligation légale et contractuelle de corriger sa
posture de sécurité.6
7
L’impact
+
L’impact
8Ponemon Institute : 2017 Cost of Data Breach Study - Canada
Coût moyen par enregistrement exposé ou voléau Canada en 2017
La menace
• 80% des entreprises auraient connu un incident de sécurité relié aux applications entre 2008 et 2010 (Gartner)
• En 2017, la probabilité de subir une fuite de données est de 25% (Ponemon)
9
10
La menace
Qui m’attaque?
Source : Verizon 2018 Data Breach Investigations Report
11
La menace
Pourquoi on m’attaque?
Source : Verizon 2018 Data Breach Investigations Report
La menace
• Jusqu’à maintenant on a surtout protégé l’infrastructure technologique.
• 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 (Gartner).
12
Citoyen
Client
Partenaire
Application web Données
Pirate 2008
13
La menace
Citoyen
Client
Partenaire
Application web
Données
Pirate 2018
14
La menace
15
La menace
Comment on m’attaque?
Source : Verizon 2018 Data Breach Investigations Report+
16
La menace
Ponemon Institute : 2017 Cost of Data Breach Study - Canada
Jours requis en moyenne pour détecter et contenir les fuites
La vulnérabilité
100 % des applications testées par TrendWave en 2017 ont des vulnérabilités
17
La vulnérabilité
• 90% des sites sont vulnérables aux attaques d'application (Watchfire)
• 78% des applications Web présentent des vulnérabilités facilement exploitables (Symantec)
• Les vulnérabilités applicatives les plus courantes (OWASP Top 10) ont peu changé en 10 ans– Nous n’apprenons pas de nos erreurs
18+
La vulnérabilité
Les organisations doivent se conformer à :• plusieurs lois et règlements
– Loi canadienne sur la protection des renseignements personnels et les documents électroniques – (PIPEDA- Personal Information Protection and Electronic Documents Act)
– Lois provinciales similaires (Québec, Alberta, C-B)– Loi sur la Protection des renseignements financiers– Loi C-198 (C-SOX) et le Règlement 52-109 – Accord de Bâle 2 – Le Code civil du Québec – La Loi sur la distribution de produits et services financiers– Le Règlement sur le cabinet, le représentant autonome et la société
autonome – Loi de l’impôt sur le revenu (Fédéral et Québec), AMF– Normes internationales d'information financière (IFRS)
19+
La vulnérabilité
• Les organisations doivent se conformer à : – des politiques et directives internes (FIPS 200) – des exigences de partenaires, de clients et
standards d’industrie, par exemple: • normes internationales d'information financière (IFRS)• PCI-DSS chapitre 6• ISO/IEC 15408 -- critères communs
20+
21
La vulnérabilité
Le contexte de nos applications évolue de façon incontrôlable
+
LA GESTION DU RISQUE DE SÉCURITÉ APPLICATIVE
“Le concept de qualité des applications, qui jusqu’icireposait sur la fonctionnalité et la performance, doitêtre étendu pour inclure la sécurité”
Neil McDonald, Sr. VP, Gartner
22
Pourquoi est-ce difficile?
• Nous avons peu de contrôle sur la menace et sur l’impact.
• Nous pouvons réduire la vulnérabilité, mais…– Il est incroyablement difficile de sécuriser une
application existante.– Il serait plus logique de développer des
applications sécuritaires.– Mais c’est difficile aussi.
23
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.24+
Pourquoi est-ce difficile?
• On entend souvent: « L’important est que l’application fonctionne. Ensuite on verra pour la sécurité ».
• Remplaçons « l’application » par « l’avion »…• Si c’est intolérable en aéronautique, pourquoi
est-ce toléré en informatique?
25+
Pourquoi est-ce difficile?
• 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
26+
Pourquoi est-ce difficile?
• 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.
27
Pourquoi est-ce difficile?
• 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
+ 28
Pourquoi est-ce difficile?
• 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.+ 29
Pourquoi est-ce difficile?
• 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
30
LA NORME ISO 27034
31
La Norme ISO 27034
• Cette norme permet à l’entreprise:– D’appliquer des contrôles de sécurité applicative
qui réduisent adéquatement le risque;– De gérer avec efficience ces contrôles de sécurité
dans tout le cycle de vie de l’application;– De démontrer que ces contrôles demeurent
efficaces.
32
33
La Norme ISO 27034
+
Il coûte 60 fois plus cher de corriger une vulnérabilitéaprès le déploiement d’une application.
La Norme ISO 27034
• 27034-1 Survol et concepts (2011)• 27034-2 Cadre normatif de l’organisation (2015)• 27034-3 Processus de gestion de la sécurité d’une
application (2018)• 27034-4 Vérification de la sécurité d’une application• 27034-5 Protocoles et structures de données (2017)• 27034-6 Exemples (2016)• 27034-7 Cadre d'assurance pour la prédiction (2018)
+ 34
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.
35
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.
36
Une nouvelle vue sur la sécurité
Personnes
Processus
Logiciels
Infrastructure
Information
ApplicationOrganisation
37
Processus
• La Norme repose sur des processus que l’organisation devrait définir ou arrimer avec ses processus existants.
• Deux niveaux de processus:– Organisationnel: gestion du Cadre normatif de
l’organisation;– Application (projet): utilisation du Cadre normatif
de l’organisation par le Processus de gestion de la sécurité d’une application.
38
Processus
Processus de gestion
Cadre Normatifde l’Organisation
Cadre Normatifde l’Application 1
Processus de gestion
Cadre Normatifde l’Application 2
Processus de gestionNiveau de
l’application(chaque projet)
Niveau de l’organisation
39
Gestion du risque de sécurité d’une application
Application Normative Framework
Processus de gestion de la sécurité d’une application
Évaluer les risques de sécurité amenés par l’application
Identifie les contextes et les
spécifications de l’application requis pour
4
3Créer et maintenir le
cadre normatif de l’application
Produit5Vé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
40
Processus de gestion de la sécurité d’une application
Évaluer les risques de sécurité amenés par l’application
Identifie les contextes et les
spécifications de l’application requis pour
4
3Créer et maintenir le
cadre normatif de l’application
Produit5Vé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
Double-clic to edit
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
Gestion du risque de sécurité d’une application
41
1
Processus de gestion de la sécurité d’une application
Évaluer les risques de sécurité amenés par l’application
Identifie les contextes et les
spécifications de l’application requis pour
4
3Créer et maintenir le
cadre normatif de l’application
Produit5Vé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
Double-clic to edit
Le propriétaire de l’application détermine le niveau de confiance ciblé
Cadre normatif de
l’organisation
On identifie, analyse et évalue les risquesOn en déduit les exigences de sécurité
Gestion du risque de sécurité d’une application
42
2
Processus de gestion de la sécurité d’une application
Évaluer les risques de sécurité amenés par l’application
Identifie les contextes et les
spécifications de l’application requis pour
4
3Créer et maintenir le
cadre normatif de l’application
Produit5Vé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
Double-clic to edit
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’applicationC’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
Gestion du risque de sécurité d’une application
43
3
Gestion du risque de sécurité d’une application
Double-clic to edit
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
Cycle de vie de l’application
Audits de l’approvisionnement de l’application
Gestion de l’infrastructure d’approvisionnement du projet Mise à la retraite
Gestion de l’approvisionnement de l’application
ArchivageTransitionPréparation Développement DestructionUtilisation
Gestion de l’infrastructure de l’application
Audits de l’opération de l’application
Gestion de l’utilisation de l’application
44
+
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
Cycle de vie de l’application
Audits de l’approvisionnement de l’application
Gestion de l’infrastructure d’approvisionnement du projet Mise à la retraite
Gestion de l’approvisionnement de l’application
ArchivageTransitionPréparation Développement DestructionUtilisation
Gestion de l’infrastructure de l’application
Audits de l’opération de l’application
Gestion de l’utilisation de l’application
Cycle de vie de l’application
Audits de l’approvisionnement de l’application
Gestion de l’infrastructure d’approvisionnement du projet Mise à la retraite
Gestion de l’approvisionnement de l’application
ArchivageTransitionPréparation Développement DestructionUtilisation
Gestion de l’infrastructure de l’application
Audits de l’opération de l’application
Gestion de l’utilisation de l’applicationOn ajoute des activités de sécurité et de vérification aux processus existants
Gestion du risque de sécurité d’une application
45
+
Gestion du risque de sécurité d’une application
• Nous conservons le lien entre un risque et les contrôles qui le réduisent.
• Nous savons quelles applications utilisent chaque contrôle.• Ceci permet une gestion des changements efficace et efficiente. 46
Risque 1
Exigence 12
Risque 2
Exigence 2
Exigence 3
Exigence 4
1
3
4
5
Processus de gestion de la sécurité d’une application
Évaluer les risques de sécurité amenés par l’application
Identifie les contextes et les
spécifications de l’application requis pour
4
3Créer et maintenir le
cadre normatif de l’application
Produit5Vé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
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
retraiteOn réalise toutes les activités de sécurité de tous les contrôlesOn réalise toutes les activités de vérification de tous les contrôles
Gestion du risque de sécurité d’une application
47
4
Gestion du risque de sécurité d’une application
Citoyen
CSA
CSA
CSA
CSA
CSA
CSA
CSA
CSA
CSA
CSA
CSA
CSA
CSA
CSA
Les contrôles sur l’application livrée
Client
Partenaire
Application web Données
48
+
Processus de gestion de la sécurité d’une application
Évaluer les risques de sécurité amenés par l’application
Identifie les contextes et les
spécifications de l’application requis pour
4
3Créer et maintenir le
cadre normatif de l’application
Produit5Vé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
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
Gestion du risque de sécurité d’une application
49
5
Gestion du risque de sécurité d’une application
• 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
50
ISO 27034 et ISO 27005
• ISO 27005 définit un processus de gestion du risque de sécurité de l’information.
• Dans ISO 27034 ce processus s’appelle « Processus de gestion de la sécurité d’une application ».
• L’arrimage avec 27005 est démontré dans le document 27034-1.
51
Context establishment
Risk analysis
Risk identification
Risk evaluation: identification of security requirements and
Application targeted level of trust
Risk treatment: Implementation of required ASCs
Ris
k m
onito
ring
and
revi
ew
Ris
k co
mm
unic
atio
n an
d co
nsul
tatio
n
No
Yes
Yes
NoRisk decision point 1Assessment satisfactory
Risk decision point 2Treatment satisfactory (all selected ASCs are correctly implemented)
Risk Assessment
Technological context
Application specifications
Regulatory context
Business context
End of first or subsequent iterations
Risk acceptance:Verification of ASC implementation,
identification of Application actual level of trust
ASC
Application actual level of trust
Application targeted level of trust
1
2
34
5
CONCLUSION
52
Conclusion
• Gérer le risque de sécurité applicative, c’est:– produire des applications sécuritaires;– demeurer en contrôle de la sécurité des
applications;– être en mesure de le démontrer.
53