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


• 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+


• 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+


• 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+


• 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


• 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


• 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


• 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





4








2

Produit


utilisés pour


1


Est utilisé pour





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


41

1





4








2

Produit


utilisés pour


1


Est utilisé pour





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é


42

2





4








2

Produit


utilisés pour


1


Est utilisé pour





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


43

3


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



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










Gestion de l’utilisation de l’application








Gestion de l’utilisation de l’applicationOn ajoute des activités de sécurité et de vérification aux processus existants


45

+


• 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





4








2

Produit


utilisés pour


1


Est utilisé pour





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


47

4


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

+





4








2

Produit


utilisés pour


1


Est utilisé pour





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


49

5


• 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

La gestion des risques de sécurité applicative des... · Les facteurs de risque • La menace:...

Documents

Transcript of La gestion des risques de sécurité applicative des... · Les facteurs de risque • La menace:...