Problèmes de SA selon le contexte d’affaires

Problèmes de SA selon le contexte d’affaires

Cette section a pour but de déterminer quels sont les secteurs d’affaires touchés par des problèmes de sécurité de l’information (confidentialité, intégrité, disponibilité) amenés par l’utilisation d’applications TI, et d’en identifier sommairement les causes et les conséquences. Les Software Engineering Notes de Neumann font mention de centaines d’accidents, dont certains mortels, impliquant l’informatique (Neumann, 1996). Au Québec, l’Association professionnelle des informaticiens et informaticiennes du Québec (APIIQ) a aussi dénombré, dans son mémoire « Encadrer la profession informatique, maintenant une nécessité! », des cas d’incidents dus à l’utilisation de systèmes d’information (Savard et Poulin, 2008). Afin de procéder à l’identification des secteurs d’affaires qui peuvent être touchés par la sécurité des informations impliquées par l’utilisation d’applications TI, Neumann propose un regroupement des différents domaines d’applications reliés à l’utilisation de systèmes d’information : les communications, l’aérospatiale, la défense, le transport, le contrôle de sécurité critique (vie humaine), le secteur médical, la création et le transport d’électricité, le secteur financier, les élections, les établissements carcéraux, le secteur juridique, etc.

Bien qu’incomplète (Neumann, 1996), car elle n’identifie pas les secteurs où peuvent être utilisées des applications TI telles que Google, Facebook et YouTube, cette classification est adéquate pour aider l’identification rapide de la majorité des secteurs d’affaires où sont utilisées les TI. Cette classification sera utilisée ci-après pour faciliter la présentation de quelques exemples de situations qui ont été répertoriés et documentés, et dans lesquelles les risques reliés à l’utilisation de systèmes d’information n’ont pas été correctement gérés. Les exemples mentionnés ci-après proviennent principalement de (Savard et Poulin, 2008). Voir l’appendice A – ANNEXE IV et ANNEXE V pour plus de renseignements sur les cas présentés en exemple dans le Tableau 1.1, qui indique, pour chacun des cas présentés, s’il a causé une perte de confidentialité (C), d’intégrité (I) ou de disponibilité (D) de données de l’application TI, ainsi que les principales conséquences résultant de ces situations. Les TI sont présentes dans presque toutes les sphères de l’activité humaine, des systèmes de radiothérapie aux systèmes comptables, de la domotique aux centrales nucléaires, des cartes à puce aux stimulateurs cardiaques, en passant par les systèmes de gestion de médicaments et les guichets automatiques. Tous les secteurs touchés par la sécurité des informations impliqués par les TI seront de plus en plus nombreux. Ces exemples démontrent que les dommages et inconvénients causés par la perte de la disponibilité, de la confidentialité ou de l’intégrité des informations reçues, traitées, conservées et communiquées par des applications peuvent parfois entraîner des conséquences très graves qui affectent tous les domaines d’affaires où des applications TI sont utilisées.

Ouvrage proposant une vision plus inclusive de la sécurité

En 2002, l’OCDE publie « Les lignes directrices de l’OCDE régissant la sécurité des systèmes et réseaux d’information : vers une culture de la sécurité » qui présente les buts et les principes que devrait soutenir la culture de la sécurité d’une organisation. Ce guide précise, notamment, que : « Seule une approche prenant dûment en compte les intérêts de toutes les parties prenantes et la nature des systèmes, réseaux et services connexes peut permettre d’assurer une sécurité efficace. L’instauration d’une culture de la sécurité … devrait se traduire par une priorité renforcée donnée à la planification et la gestion de la sécurité, ainsi que par une compréhension de l’exigence de sécurité par l’ensemble des participants. » (OCDE, 2002, p. 18). De ces ouvrages présentant une vision plus inclusive de la sécurité, aucun guide ou méthode de réalisation d’applications n’offre une vision globale permettant d’identifier formellement « les intérêts de toutes les parties prenantes et la nature des systèmes, réseaux et services connexes » (OCDE, 2002, p. 18) à l’application afin de pouvoir gérer efficacement sa sécurité. Cette problématique provient de l’absence d’une vision globale des principes et des éléments impliqués dans la sécurité des applications (P01)8.

Finalement, l’OCDE présente dix principes, dont l’importance de gérer la sécurité en évaluant continuellement les risques (OCDE, 2002, pp. 19-23). C’est à cet effet qu’ISO a pris l’initiative du développement de la norme ISO 27001 Information technology – Security techniques – Information security management systems – Requirements (ISO/IEC, 2005d) pour la mise en place du SGSI dans l’organisation, et ce, afin de lui permettre de gérer de façon cohérente la sécurité de son information. L’objectif du développement de cette norme était de définir un cadre normatif contenant l’ensemble des exigences minimales à respecter pour la mise en place d’un système de gestion de la sécurité de l’information basé sur une approche de gestion du risque. Constatant que ce type de cadre normatif n’existait pas encore en SA, j’ai intégré ce premier élément au modèle SA initial, afin qu’il identifie les éléments qui devraient être utilisés pour protéger l’application d’une organisation et les éléments qui ne sont pas nécessaires (P03). Andress propose une vision différente de la gestion de la sécurité de l’information qui intègre les personnes, les processus et la technologie comme sources de risques pour la sécurité de l’information (Andress, 2003, pp. 5, 453-468), (P15). Elle y introduit l’importance de gérer les risques de sécurité, de définir des exigences de sécurité (P09) et de mettre en place des processus de gestion de la sécurité (Andress, 2003, pp. 25-43), (P12). Andress présente aussi un ensemble de menaces et de solutions concernant autant la sécurité des postes de travail et la sécurité des serveurs, que la sécurité dans le développement d’applications, ainsi que la maintenance et la surveillance de l’infrastructure technologique de l’organisation (Andress, 2003, pp. 25-43). Cet ouvrage a innové puisqu’il est l’un des premiers à identifier les principaux éléments dont il faut tenir compte simultanément, tout en tentant de garder une vision plus globale (P01) en se concentrant sur les problématiques de sécurité des processus organisationnels ou sur les menaces pouvant compromettre des composants technologiques.

Ouvrages proposant la gestion des risques pour implémenter la sécurité

En publiant ISO 27002 Information technology – Security techniques – Information security management systems – Code of practice for information security management en 2002, puis en la rééditant en 2013, l’ISO a décrit un ensemble de contrôles de sécurité qui devrait être mis en place au sein d’une organisation, afin de lui permettre d’assurer la protection de son information (ISO/IEC, 2005c), (ISO/IEC, 2013b). Même si la majorité des contrôles qui y sont présentés concernent des risques de sécurité organisationnels, certains d’entre eux concernent spécifiquement la SA, notamment « le contrôle d’accès d’un système ou d’une application » et « le contrôle d’accès au code source ». Du fait de leurs descriptions générales, leur mise en oeuvre dépend spécifiquement des connaissances et de l’interprétation des personnes qui sont responsables de cette mise en oeuvre. De fait, après avoir identifié trois catégories de contrôles de sécurité, soit : les contrôles techniques, les contrôles opérationnels et les contrôles de gestion, Baker et Wallace ont mesuré la qualité de leur mise en oeuvre dans diverses organisations.

Il en résulte que même si ces dernières mettent en place des contrôles de sécurité, plusieurs d’entre elles gèrent la mise en oeuvre de ces contrôles et, par le fait même de leur sécurité, de manière inconsistante et superficielle (Baker et Wallace, 2007) (P03, P10 et P13). Plusieurs méthodes d’analyse de risques de sécurité ont été développées, autant par des organisations nationales qu’internationales (SEI, 2001), (Alberts et al., 2005), (DCSSI, 2004), (CLUSIF, 2005). Elles ont toutes pour objectif d’aider les organisations à identifier et à gérer les risques de sécurité, à utiliser des systèmes TI en prenant en compte la sensibilité des informations présentes dans l’organisation, les applications et les manipulations, ainsi que les infrastructures TI qui soutiennent ces dernières. Par contre, elles s’utilisent toutes au niveau organisationnel, et elles n’offrent pas le niveau de granularité nécessaire à l’identification des risques et des contrôles de sécurité pouvant être intégrés à une application. Ces méthodes d’analyse de risques de sécurité se réfèrent toutes à ISO 27005 Information technology – Security techniques – Information security risk management (ISO/IEC, 2010d) pour démontrer qu’elles sont conformes aux exigences minimales de gestion de risques qui y sont présentées.

Malheureusement, même si l’OCDE le recommande, peu de méthodes de développement et de processus de gestion de projets d’applications incluent des activités permettant d’identifier et de tenir en compte les risques provenant des contextes d’une application. Cette absence d’une vision permettant d’identifier et de tenir en compte les risques et les contextes d’utilisation d’une application est une des grandes problématiques de la SA (P02), car les risques de SA ne peuvent pas tous être identifiés par les intervenants d’un seul secteur d’intervention. Une première tentative de développement d’une méthode d’analyse de risques de sécurité, qui offrirait un niveau de granularité adapté aux applications, a été réalisée par le NIST avec la publication, en 2002, de la norme SP 800-30 – Risk Management Guide for Information Technology Systems (Stoneburner, Goguen et Feringa, 2002).

Ce document vise principalement à aider les organisations qui développent des systèmes TI à identifier et à gérer des risques de sécurité pouvant se retrouver durant le cycle de vie de développement d’une application (Stoneburner, Goguen et Feringa, 2002, p. 4). Cette approche a récemment été étendue par le NIST au cycle de vie complet de l’application en publiant une révision du guide SP 800-37 Rev 1 – Guide for Applying the Risk Management Framework to Federal Information Systems – A Security Life Cycle Approach et en l’orientant non plus sur la certification d’une application, mais sur la gestion des risques (NIST, 2010). La démarche proposée s’adresse principalement à une audience oeuvrant soit au niveau de la gouvernance, soit au niveau du développement et de la maintenance d’applications. De plus, ne présentant que des contrôles de haut niveau, l’approche proposée par ce guide, tout comme les démarches proposées par les analyses de risques organisationnels, ne permet pas d’identifier précisément ni les besoins de sécurité, ni les activités de SA à mettre en oeuvre pour estimer les coûts liés à ces activités, à leurs vérifications et à leur maintien (P04).

Table des matières

INTRODUCTION
CHAPITRE 1 TRAVAUX PRÉPARATOIRES
1.1 Motivation du chercheur
1.2 Sécurité de l’information et gestion du risque
1.3 Contextes de la sécurité de l’information
1.4 Analyse de l’impact de ces contextes sur la sécurité des applications (SA)
1.4.1 Problèmes de SA selon le contexte d’affaires
1.4.2 Problèmes de SA selon le contexte juridique
1.4.3 Problèmes de SA selon le contexte technologique
1.5 Synthèse de la problématique de la SA
CHAPITRE 2 OBJECTIFS ET MÉTHODOLOGIE DE RECHERCHE
2.1 Question de recherche
2.2 Enjeux de la sécurité de l’information dans les applications
2.3 But de la recherche
2.4 Objectifs de recherche
2.5 Stratégies de recherche
2.5.1 Axe de la stratégie de conception du modèle SA
2.5.2 Axe de la stratégie de validation
2.5.3 Axe de la stratégie de vérification partielle
2.5.4 Axe de la stratégie de diffusion
2.6 Méthodologie de recherche
2.6.1 Description sommaire de la méthodologie de la recherche
2.6.2 Sélection de la méthode Delphi
2.6.3 Adaptation de la méthode Delphi au projet de recherche
2.6.4 Vision globale de la méthodologie de recherche
2.6.5 Critères à rencontrer durant la recherche
CHAPITRE 3 REVUE DE LITTÉRATURE
3.1 Objectifs de la revue de littérature
3.2 Sélection et classement des ouvrages consultés sous l’angle de la SA
3.3 Documents couverts par la revue de littérature
3.3.1 Ouvrages liés à la gouvernance de la sécurité de l’information et des applications
3.3.2 Ouvrages liés à l’intégration d’éléments de sécurité dans les phases de développement, d’acquisition ou de maintenance d’applications
3.3.3 Ouvrages liés à l’environnement et l’infrastructure technologiques des applications
3.3.4 Ouvrages liés à la vérification et aux audits de SA
3.4 Identification des éléments de réponses aux problématiques en SA
3.5 Constats de la revue de littérature
3.5.1 Synthèse des éléments provenant d’articles scientifiques
3.5.2 Synthèse des pistes de solutions proposées par les ouvrages consultés
3.6 Revue complémentaire
3.6.1 Analyse rétroactive des travaux de maîtrise du chercheur en sécurité informatique
3.6.2 Analyse rétroactive du cours universitaire de premier cycle en sécurité appliquée développé par le chercheur
3.6.3 Analyse rétroactive des certifications professionnelles obtenues par le chercheur en sécurité de l’information et des applications
3.6.4 Analyse rétroactive de la démarche et des résultats de l’audit de sécurité des applications dirigée par le chercheur
3.7 Termes et définitions retenus pour ce travail de recherche
CHAPITRE 4 CONCEPTION DU MODÈLE DE LA SÉCURITÉ DES APPLICATIONS
4.1 Synthèse des travaux de recherche
4.1.1 Besoins de l’audience visée
4.1.2 Évolution de la portée du modèle SA
4.1.3 Principes identifiés par le modèle SA
4.1.4 Termes définis dans le modèle SA
4.1.5 Concepts intégrés au modèle SA
4.1.6 Composants du modèle SA
4.1.7 Groupes et rôles d’acteurs identifiés dans le modèle SA
4.1.8 Processus identifiés par le modèle SA
CHAPITRE 5 LE MODÈLE DE LA SÉCURITÉ DES APPLICATIONS
5.1 Ce qu’implique la SA
5.2 Éléments du modèle SA
5.3 Enjeux de la mise en place du modèle SA
5.3.1 Priorisation des éléments du modèle à mettre en place
5.3.2 Formalisation du CNO
5.3.3 Engagement d’investissement des ressources appropriées
5.3.4 Participation des intervenants liés aux quatre domaines d’intervention couverts par le modèle SA
5.4 Caractéristiques du modèle SA et réponses aux problématiques identifiées
5.5 Besoins de l’audience ciblée par le modèle SA
5.5.1 Besoins des gestionnaires
5.5.2 Besoins des équipes d’approvisionnement et d’opération
5.5.3 Besoins des vérificateurs et des auditeurs
5.5.4 Besoins des acheteurs
5.5.5 Besoins des fournisseurs
5.5.6 Besoins des utilisateurs
5.6 Portée du modèle SA
5.7 Principes clés de la SA
5.7.1 La SA doit être gérée
5.7.2 La SA est une exigence
5.7.3 La SA est dépendante de l’environnement de l’application
5.7.4 La SA nécessite les ressources appropriées
5.7.5 La SA doit pouvoir être démontrée
5.8 Concepts et définitions introduits par le modèle SA
5.8.1 Application
5.8.2 Environnement d’une application
5.8.3 Contexte d’affaires de l’application
5.8.4 Contexte juridique de l’application
5.8.5 Contexte technologique de l’application
5.8.6 Spécifications et fonctionnalités de l’application
5.8.7 Groupes d’informations liées à la SA
5.8.8 Risques de la SA
5.8.9 Exigences de la SA
5.8.10 Contrôles de SA
5.8.11 Vulnérabilités d’une application
5.8.12 Niveau de confiance d’une application
5.8.13 Application sécuritaire
5.9 Composants du modèle SA
5.9.1 Comité de gestion du CNO
5.9.2 Cadre normatif de l’organisation (CNO)
5.9.3 Contexte d’affaires
5.9.4 Contexte juridique
5.9.5 Contexte technologique
5.9.6 Dépôt des spécifications et des fonctionnalités des applications
5.9.7 Dépôt des rôles, responsabilités et qualifications
5.9.8 Dépôt des groupes d’informations catégorisés
5.9.9 Contrôle de sécurité des applications (CSA)
5.9.10 Bibliothèque de CSA
5.9.11 Matrice de traçabilité de la SA
5.9.12 Modèle de référence du cycle de vie de la SA (MRCVSA)
5.9.13 Modèle du cycle de vie de la sécurité d’une application
5.9.14 Cadre normatif de l’application (CNA)
5.10 Processus du modèle SA
5.10.1 Gérer le comité du CNO
5.10.2 Gestion du CNO
5.10.3 Gestion des risques de la SA
5.10.4 Gestion de la SA
5.10.5 Audit et certification de la mise en oeuvre du modèle SA
CHAPITRE 6 VALIDATION DU MODÈLE SA
6.1 Validation du modèle SA à l’aide de la méthode Delphi
6.2 Vérification empirique partielle du modèle SA
6.2.1 Processus de vérification empirique partielle de l’applicabilité et de l’acceptabilité des éléments du modèle SA par les organisations
6.2.2 Conception de l’étude de cas
6.2.3 Préparation de la collecte des données
6.2.4 Collecte des données : présentation et utilisation du modèle en industrie
6.2.5 Rapport : interprétation des mesures empiriques et de l’impact du modèle dans l’industrie
6.3 Évaluation de la qualité des mesures de la méthode ASIA
6.3.1 Objectif
6.3.2 Démarche
6.3.3 Évaluation des critères et activités de mesure
6.3.4 Résultats
6.4 Comparaison de l’impact du modèle sur la sécurité des systèmes de votation des projets DGÉQ 2006 et ÉC 2010
6.5 Compilation des réponses apportées par le modèle SA aux problématiques de la sécurité des applications
6.6 Positionnement du modèle SA avec les pratiques et normes existantes
CHAPITRE 7 CONTRIBUTIONS DU CHERCHEUR ET ATTEINTE DES OBJECTIFS DE RECHERCHE
7.1 Éléments clés du modèle SA et contributions du chercheur
7.2 Atteintes des objectifs de recherche
7.2.1 Premier objectif : développer un modèle SA qui répond aux critères du but de la recherche
7.2.2 Deuxième objectif : s’assurer que le modèle permette d’intégrer des contrôles de sécurité durant tout le cycle de vie d’une application
7.2.3 Troisième objectif : munir le modèle SA de mécanismes permettant de fournir à l’organisation les preuves que son application a atteint et maintient le niveau de confiance préalablement ciblé, et ce, en fonction de son contexte d’utilisation spécifique
7.2.4 Quatrième objectif : faire vérifier le modèle SA par plusieurs
vérificateurs experts, délégués par différentes instances nationales compétentes
7.2.5 Cinquième objectif : faire approuver le modèle par une organisation internationale de normalisation
7.2.6 Sixième objectif : rendre le modèle SA accessible à toute organisation désirant mettre en place ou vérifier la sécurité d’applications
CHAPITRE 8 CONCLUSION
8.1 Résultats de la recherche
8.2 Éléments soutenant la crédibilité du modèle SA
8.3 Limites du modèle SA
8.4 Impacts sur l’industrie
8.4.1 Événements et constats d’adoption du modèle SA par l’industrie
8.5 Travaux futurs
ANNEXE I TABLEAUX ET FIGURES
ANNEXE II PATERNITÉ DU MODÈLE SA
ANNEXE III LISTE DES APPENDICES
BIBLIOGRAPHIE

Télécharger le rapport complet