Du point de vue de la sécurité des TIC, la gestion des risques est le processus d'identification et de traitement des facteurs susceptibles d'entraîner une atteinte à la confidentialité, à l'intégrité ou à la disponibilité d'un système d'information. Le risque est fonction de la probabilité qu'une source de menace exploite une vulnérabilité potentielle spécifique et de l'impact/de la criticité d'un tel événement indésirable sur l'organisation. Une menace représente la possibilité pour une source de menace d'exploiter (accidentellement ou intentionnellement) une vulnérabilité spécifique. Une source de menace peut être une tentative ou une méthode visant à exploiter intentionnellement une vulnérabilité, ou une situation ou une méthode susceptible de déclencher accidentellement une vulnérabilité. Une vulnérabilité est une faiblesse, un défaut ou une faille/un bogue dans les procédures de sécurité, la conception, la mise en œuvre ou les contrôles internes du système, qui peut être déclenchée (accidentellement ou intentionnellement) et entraîner une violation de la sécurité ou de la politique de sécurité du système. Il existe de nombreuses méthodologies d'analyse et de gestion des risques, et le choix de l'une plutôt que d'une autre dépend des facteurs organisationnels spécifiques. Cependant, on peut supposer que celles qui permettent l'élaboration de principes de sécurité adaptés aux marchés et aux profils des organisations suscitent un plus grand intérêt et sont davantage adoptées. De même, il semble très bénéfique d'impliquer tous les membres de l'organisation en tant que participants, en utilisant des outils tels que la création de réunions dédiées.
Méthodologie d'évaluation des risques OCTAVE. Évolution des
méthodes OCTAVE. OCTAVE (Évaluation des menaces, des actifs et des vulnérabilités critiques sur le plan opérationnel) est une méthodologie qui améliore la prise de décision relative à la protection et à la gestion des ressources d'une organisation, et constitue également un outil d'analyse des risques. On distingue deux principales méthodes OCTAVE : l'une destinée aux grandes entreprises de plus de 300 employés, et l'autre, OCTAVE-S, aux organisations de plus petite taille (PME, par exemple). En juin 1999, l'Université Carnegie Mellon a publié le cadre OCTAVE, version 1.0. En septembre 2001, la méthode OCTAVE, version 2.0, a été publiée, suivie en décembre 2001 par les critères OCTAVE, également version 2.0, tous destinés aux grandes organisations à structure hiérarchique complexe. En septembre 2003, la version 0.9 d'OCTAVE-S a été lancée, suivie de la version 1.0 en mars 2005. Ces versions étaient adaptées aux petites organisations (de 20 à 80 employés) à structure hiérarchique horizontale. En juin 2007, la version 1.0 d'OCTAVE Allegro a été publiée, renforçant la capacité des organisations à réaliser des évaluations des risques. Par exemple, lorsque les actifs informationnels sont au cœur de l'évaluation des risques de sécurité, les autres actifs connexes sont considérés comme des référentiels d'information, c'est-à-dire des systèmes qui stockent, traitent ou transportent ces actifs. Les référentiels d'information peuvent être des personnes, des objets (documents) ou des technologies (bases de données). Les menaces pesant sur les actifs informationnels sont analysées en tenant compte de leur emplacement et en limitant le nombre et les types d'actifs inclus dans le processus.
Les principaux aspects d'OCTAVE peuvent être identifiés comme suit : (i) Il est autonome ; le personnel de l'organisation réalise l'évaluation et connaît ses exigences et ses opérations. (ii) Il se concentre sur les risques organisationnels, les enjeux stratégiques et ceux liés aux pratiques. (iii) Il s'appuie sur une petite équipe composée de personnes issues des unités opérationnelles (métier) et du département informatique. (iv) Son approche est fondée sur les pratiques de sécurité et de gestion des risques opérationnels ; la technologie n'est examinée qu'en lien avec ces pratiques. OCTAVE établit ainsi un équilibre entre trois aspects : les risques opérationnels, la technologie et les pratiques de sécurité. OCTAVE s'adapte à différents points de départ et d'arrivée dans les activités de gestion des risques d'une organisation ; il peut être mis en œuvre ponctuellement ou de manière périodique.
Les principales différences relevées par rapport aux autres méthodes sont les suivantes : (a) Elle permet l’évaluation des organisations, contrairement aux autres méthodes qui n’évaluent que le système. (b) Elle se concentre sur les pratiques de sécurité, tandis que les autres méthodes se concentrent uniquement sur la technologie. (c) Elle aborde les enjeux stratégiques, contrairement aux autres méthodes qui ne traitent que des enjeux tactiques. (d) Elle favorise l’autonomie, contrairement aux autres méthodes qui sont mises en œuvre uniquement par des experts.
OCTAVE présente trois caractéristiques clés : (i) Une équipe interdisciplinaire, appelée équipe d’analyse, réalise l’évaluation. (ii) Pour caractériser la vision globale des risques liés à la sécurité de l’information au sein de l’organisation, deux perspectives importantes sont prises en compte : métier et informatique. (iii) Il s’agit d’une approche d’évaluation axée sur les actifs. L’évaluation des risques d’OCTAVE repose sur trois principes fondamentaux de gestion de la sécurité : confidentialité, intégrité et disponibilité. Grâce à une classification simple des informations critiques, un plan de protection est généré pour ces informations. OCTAVE définit une approche systématique et globale de l’évaluation des risques liés à la sécurité de l’information.
L'approche OCTAVE est définie par un ensemble de critères comprenant des principes, des attributs et des résultats : (1) Principes. Ce sont des concepts fondamentaux qui orientent la nature de l'évaluation. Ils constituent l'approche et en fournissent la base. Par exemple, l'autonomie est l'un des principes OCTAVE. Ce concept signifie que les personnes au sein de l'organisation sont les mieux placées pour mener l'évaluation et la prise de décision. Les exigences de l'évaluation sont intégrées aux attributs et aux résultats. (2) Attributs. Ce sont des qualités ou caractéristiques distinctives de l'évaluation. Ils définissent les facteurs de réussite de l'évaluation. Ce sont les exigences qui définissent les éléments de base de l'approche OCTAVE. Ils définissent ce qui est nécessaire à la réussite de l'évaluation, tant du point de vue du processus que de l'organisation. Les attributs découlent des principes. Par exemple, l'un des attributs OCTAVE est qu'une équipe multidisciplinaire, appelée équipe d'analyse et composée de personnel interne à l'organisation, dirige l'évaluation. Le principe sous-jacent à la création d'une équipe d'analyse est l'autonomie. (3) Résultats. Il s'agit du résultat attendu de chaque phase. Aucune activité unique n'est définie, car plusieurs activités peuvent être menées pour atteindre les objectifs d'OCTAVE. Ces objectifs définissent les résultats qu'une équipe d'analyse doit produire au cours de l'évaluation.
Phases d'évaluation des risques OCTAVE :
L'approche OCTAVE permet aux organisations de comprendre, d'évaluer et de gérer leurs risques liés à la sécurité de l'information d'un point de vue organisationnel. OCTAVE n'est pas un produit, mais une méthodologie axée sur les processus pour identifier, hiérarchiser et gérer les risques liés à la sécurité de l'information. OCTAVE permet aux organisations d'effectuer plusieurs fonctions : (i) Élaborer des critères d'évaluation qualitative des risques en fonction des seuils de tolérance au risque opérationnel. (ii) Identifier les actifs critiques pour l'organisation. (iii) Identifier les vulnérabilités et les menaces pesant sur les actifs critiques. (iv) Déterminer et évaluer les conséquences potentielles pour l'organisation en cas de concrétisation des menaces. (v) Mettre en œuvre des actions correctives pour atténuer les risques et créer une stratégie de protection fondée sur les meilleures pratiques.
Dans le processus OCTAVE, trois phases d'évaluation des risques peuvent être identifiées et mises en œuvre sous forme d'ateliers successifs : (1) Phase 1 (Vision organisationnelle – Évaluation). Cette phase consiste à établir des profils de menaces basés sur les actifs. Les actifs importants sont identifiés, ainsi que les mesures de protection nécessaires et les exigences de sécurité propres à chaque actif. L'équipe d'analyse détermine les actifs critiques et les mesures de protection actuellement mises en œuvre. Les exigences de sécurité sont définies pour chaque actif critique. Enfin, les vulnérabilités organisationnelles sont établies à partir des pratiques existantes et le profil de menaces de chaque actif critique est défini. (2) Phase 2 (Vision technologique – Évaluation). L'équipe d'analyse identifie les chemins d'accès au réseau et les classes de composants TIC liés à chaque actif critique. Elle détermine ensuite le niveau de résistance de chaque classe de composants aux attaques réseau et identifie les vulnérabilités technologiques exposant les actifs critiques. Cette phase implique l'identification des vulnérabilités de l'infrastructure technique. Les chemins d'accès au réseau et les classes de composants TIC de chaque actif sont examinés, et la résistance aux attaques réseau est déterminée. (3) Phase 3 (Élaboration des plans et de la stratégie de sécurité). L'équipe d'analyse identifie et évalue les risques pesant sur les actifs critiques de l'organisation à partir des informations recueillies et détermine les mesures à prendre. Elle élabore une stratégie de protection et des plans d'atténuation pour gérer les risques identifiés. L'équipe définit également les prochaines étapes nécessaires à la mise en œuvre et à l'obtention de l'approbation de la direction générale pour l'ensemble du processus. Les risques pesant sur les actifs critiques sont identifiés, des stratégies de protection et des plans d'atténuation sont élaborés, et l'analyse s'appuie sur les phases précédentes.
Phases d'évaluation des risques avec OCTAVE-S et OCTAVE-Allegro.
Dans le cadre du processus OCTAVE-S, pour les petites organisations, les quatre étapes suivantes peuvent être identifiées : (1) Étape 1 (Identification des informations organisationnelles). Il s'agit d'identifier les connaissances de la direction générale, celles de la direction opérationnelle et celles du personnel. (2) Étape 2 (Élaboration des profils de menaces par actif). Il s'agit de créer le profil de menaces, c'est-à-dire d'identifier les vulnérabilités de l'organisation et les menaces actuelles pesant sur chaque actif critique. (3) Étape 3 (Identification des vulnérabilités de l'infrastructure). Il s'agit d'identifier les composants clés et d'évaluer certains composants issus de l'évaluation technologique. L'équipe d'analyse examine l'infrastructure informatique afin d'identifier les composants liés aux actifs critiques et les vulnérabilités technologiques connues. (4) Étape 4 (Élaboration de la stratégie de protection et du plan d'atténuation). Il s'agit d'analyser les risques et de sélectionner l'approche d'atténuation.
Dans le processus OCTAVE-Allegro, les huit processus suivants peuvent être identifiés et organisés en quatre phases : (1) Phase 1 (Définition des facteurs clés). L’organisation élabore des critères de mesure des risques cohérents avec ses facteurs clés. Cette phase inclut le processus 1, qui établit les critères de gestion des risques. (2) Phase 2 (Profilage des actifs). Les actifs informationnels jugés critiques sont identifiés et leurs profils sont générés. Ce processus de profilage définit clairement les limites de l’actif, identifie ses exigences de sécurité et recense tous les lieux où il est stocké, transporté ou traité. Cette phase inclut les processus suivants : (i) Processus 2, Élaboration du profil de l’actif informationnel. (ii) Processus 3, Identification des conteneurs d’actifs informationnels. (3) Phase 1 (Identification des menaces). Les menaces pesant sur les actifs informationnels critiques sont identifiées en fonction des lieux où ils sont stockés, transportés ou traités. Cette phase inclut les processus suivants : (i) Processus 4, Identification des zones d’intérêt. (ii) Processus 5, Identification des scénarios de menaces. (4) Phase 4 (Identification et atténuation des risques). Les risques pesant sur les actifs informationnels sont identifiés et analysés, et des mesures d'atténuation sont élaborées. Cela comprend les processus suivants : (i) Processus 6 : identification des risques ; (ii) Processus 7 : analyse des risques ; (iii) Processus 8 : sélection de la mesure d'atténuation.
Processus de modélisation et d'analyse des menaces. Microsoft. Catégories STRIDE et DREAD.
Le processus de modélisation des risques liés aux menaces de Microsoft, conçu pour la sécurité du développement d'applications web, comporte cinq étapes : (i) Identification des objectifs de sécurité. Les objectifs de sécurité d'une application peuvent être classés dans les catégories suivantes : (a) Identité. Déterminer si l'application protège l'identité de l'utilisateur contre les abus potentiels. (b) Perte financière. Élevée s'il s'agit d'une application bancaire. (c) Atteinte à la réputation en cas de mauvaise utilisation ou d'attaque de l'application. (d) Protection des données utilisateur (confidentialité, conformité réglementaire). (e) Garanties de disponibilité. L'application nécessite un accord de niveau de service (SLA). (ii) Analyse de l'architecture et de la conception de l'application. Examiner les composants UML, les flux de données et les limites de confiance. (iii) Décomposition de l'application en modules (par exemple, le module d'authentification, la validation des données saisies et les hypothèses du module) et en fonctionnalités. (iv) Identification des menaces et des vulnérabilités, utilisation de STRIDE/DREAD, puis retour à l'étape (ii). Parmi les menaces possibles : un attaquant peut lire les messages d'autres utilisateurs ; L'utilisateur ne peut pas se déconnecter d'un ordinateur partagé ; une validation des données insuffisante peut permettre une injection SQL ; l'autorisation peut échouer, autorisant un accès non autorisé ; le cache du navigateur web peut contenir le contenu des messages. Les contre-mesures comprennent : la mise en œuvre de la validation des données ; la mise en œuvre de contrôles d'autorisation ; la mise en œuvre de directives anti-cache dans les en-têtes HTTP ; et l'utilisation de SSL/TLS/SSH si le risque d'écoute clandestine est élevé. Les entités susceptibles d'attaquer une application comprennent : une découverte accidentelle par un utilisateur ordinaire en raison d'une erreur fonctionnelle de l'application ; des logiciels malveillants automatisés (scripts/programmes qui recherchent des vulnérabilités) ; des attaquants curieux ; des personnes mal intentionnées ; des attaquants professionnels ; le crime organisé, etc.
STRIDE est un système de classification permettant de caractériser les menaces connues selon les types d'exploits utilisés ou les motivations de l'attaquant. L'acronyme STRIDE est formé à partir de la première lettre de chacune des catégories suivantes : (1) Usurpation d'identité (S). Il s'agit d'un risque majeur pour les applications comptant de nombreux utilisateurs mais offrant un contexte d'exécution unique au niveau de l'application ou de la base de données. Concrètement, les utilisateurs ne doivent pas pouvoir usurper l'identité d'un autre utilisateur ni s'approprier ses attributs. (2) Altération des données (T). Les utilisateurs peuvent potentiellement modifier les données qui leur sont transmises, les renvoyer et, par conséquent, manipuler la validation côté client, les résultats des requêtes GET et POST, les cookies, les en-têtes HTTP, etc. L'application ne doit pas envoyer à l'utilisateur de données, telles que les taux d'intérêt ou les périodes, qui ne peuvent être obtenues qu'au sein même de l'application. L'application doit également vérifier soigneusement les données reçues de l'utilisateur et s'assurer de leur exactitude et de leur applicabilité avant de les stocker ou de les utiliser. (3) Répudiation (R). Les utilisateurs peuvent contester et répudier des transactions en cas d'audit ou de journalisation insuffisants de leurs activités. Par exemple, si un utilisateur déclare : « Je ne transfère pas d’argent vers ce compte externe », et que ses activités ne peuvent être suivies par l’application, la transaction sera très probablement comptabilisée comme une perte. Par conséquent, il convient d’examiner si l’application nécessite des mécanismes de non-répudiation, tels que des journaux d’accès web, des journaux d’audit à chaque niveau, ou l’utilisation d’un contexte utilisateur unique de bout en bout. Idéalement, l’application devrait s’exécuter avec les privilèges de l’utilisateur, et rien de plus, mais cela peut s’avérer impossible avec de nombreuses plateformes. (4) Divulgation d’informations (I). Les utilisateurs sont légitimement réticents à divulguer des informations personnelles à un système. Si un attaquant peut divulguer publiquement des données utilisateur en grande quantité, de manière anonyme ou en tant qu’utilisateur autorisé, la confidentialité sera immédiatement compromise et la réputation de l’entreprise sera fortement affectée. Par conséquent, les applications doivent intégrer des contrôles robustes pour empêcher la capture et l’utilisation abusive de l’identifiant utilisateur, en particulier si elles utilisent un contexte unique pour exécuter l’ensemble de l’application. Il est également important de vérifier si le navigateur web de l’utilisateur est susceptible de divulguer des informations. Certains navigateurs web peuvent ignorer ou mal interpréter les directives « no-caching » dans les en-têtes HTTP. De même, toute application sécurisée a la responsabilité de minimiser la quantité d'informations stockées par le navigateur web, car un attaquant pourrait utiliser ces informations pour obtenir des détails sur l'application, l'utilisateur, voire se faire passer pour cet utilisateur en cas de fuite de données. Lors de la mise en œuvre de valeurs persistantes, il convient de garder à l'esprit que l'utilisation de champs cachés est intrinsèquement non sécurisée. Un tel stockage ne doit pas reposer sur des informations sensibles et confidentielles ni offrir de garanties suffisantes pour la protection de la vie privée. (5) Déni de service (D). Les concepteurs d'applications doivent être conscients que leurs applications peuvent être la cible d'attaques par déni de service. Par conséquent, l'utilisation de ressources coûteuses telles que les fichiers volumineux, les calculs complexes, les recherches intensives ou les requêtes longues doit être réservée aux utilisateurs authentifiés et autorisés et ne doit pas être mise à la disposition des utilisateurs anonymes. Pour les applications qui ne disposent pas de ces ressources, chaque aspect de l'application doit être conçu pour effectuer le moins de travail possible, utiliser peu de requêtes de base de données et privilégier les requêtes rapides, et éviter l'exposition à des fichiers volumineux ou à des liens uniques par utilisateur afin de prévenir les attaques par déni de service. (6) Élévation de privilèges (E). Si une application propose des rôles d'administrateur et d'utilisateur distincts, il est essentiel d'empêcher l'utilisateur d'obtenir des privilèges supérieurs. Concrètement, le simple fait de ne pas afficher les liens vers les rôles privilégiés est insuffisant. Toutes les actions doivent être contrôlées par une matrice d'autorisation afin de garantir que seuls les rôles autorisés puissent accéder aux fonctionnalités privilégiées.
DREAD est un système de classification permettant de quantifier, comparer, classer et prioriser le niveau de risque présenté par chaque menace évaluée. La valeur du risque est calculée à l'aide de la formule suivante : Risque DREAD = (Dommages potentiels + Reproductibilité + Exploitabilité + Utilisateurs affectés + Découvrabilité) / 5. L'acronyme DREAD est formé à partir de la première lettre de chacune des catégories suivantes : (1) Dommages potentiels (D). Détermine l'ampleur des dommages que la menace pourrait causer si elle se concrétisait. Lié à la notion d'impact. Une façon de quantifier cette catégorie DREAD est la suivante : Aucun = 0 ; Données utilisateur individuelles affectées ou compromises = 5 ; Destruction complète des données ou du système = 10. (2) Reproductibilité (R). Détermine la facilité avec laquelle l'exploitation de la menace peut être reproduite. Lié à la notion de probabilité. Une façon de quantifier cette catégorie DREAD est la suivante : Très difficile ou impossible, même pour les administrateurs d'applications = 0. (3) Exploitabilité (E). Détermine les éléments nécessaires pour exploiter cette menace. Également lié à la notion de probabilité. Une façon de quantifier cette catégorie DREAD est la suivante : Connaissances avancées en programmation et en réseau, avec des outils d’attaque avancés ou personnalisés = 0 ; Présence de logiciels malveillants sur Internet ou exploitation facile à l’aide d’outils d’attaque disponibles = 5 ; Un simple navigateur Web = 10. (4) Utilisateurs affectés (A). Détermine le nombre d’utilisateurs qui seront affectés. Également lié à la notion d’impact. Une façon de quantifier cette catégorie DREAD est la suivante : Aucun = 0 ; Certains utilisateurs, mais pas tous = 5 ; Tous les utilisateurs = 10. (5) Découvrabilité (D). Détermine la facilité avec laquelle cette menace est détectée. Également lié à la notion de probabilité. Une façon de quantifier cette catégorie DREAD est la suivante : Très difficile ou impossible, nécessite le code source ou un accès administrateur = 0 ; Détectable par la surveillance des traces réseau = 5 ; Les détails de ces défaillances sont déjà publics et facilement accessibles à l’aide d’un moteur de recherche performant comme Yahoo/Google = 9 ; L’information est visible dans la barre d’adresse du navigateur Web ou sous une forme = 10.
Considérations finales.
Notre groupe de recherche travaille depuis plus de vingt ans dans le domaine de l'analyse, de l'évaluation et de la gestion des risques liés aux réseaux, aux technologies, aux organisations, aux unités opérationnelles, ainsi qu'aux écosystèmes et environnements où les TIC et les entreprises interagissent. Différentes méthodologies et approches ont été mises en œuvre.
Cet article s'inscrit dans le cadre des activités menées au sein du réseau thématique LEFIS.
Bibliographie
- Areitio, J. « Sécurité de l’information : réseaux, informatique et systèmes d’information ». Cengage Learning-Paraninfo. 2012.
- Areitio, J. « Gestion des identités, confidentialité stratégique pour minimiser les risques liés à la sécurité de l’information ». Conectrónica Magazine. N° 146. Avril 2011.
- OCTAVE : http://www.cert.org/octave/
- Landoll, D. « Manuel d’évaluation des risques : un guide complet pour la réalisation d’évaluations des risques de sécurité ». 2e édition. CRC Press. 2011.
- Pertier, TR « Analyse des risques liés à la sécurité de l’information ». 3e édition. Auerbach Publications. 2010.
- Norman, TL « Analyse des risques et sélection des contre-mesures de sécurité ». CRC Press. 2009.
- Vose, D. « Analyse des risques : un guide quantitatif ». Wiley. 3e édition. 2008.
- Tipton, HF « Manuel de gestion de la sécurité de l’information ». 6e édition. Vol. 3. Auerbach Publications. 2009.
- Gollmann, D. « Sécurité informatique ». 3e édition. Wiley. 2011.
Auteur:
Prof. Dr. Javier Areitio Bertolín – E.Mail :
Professeur à la Faculté d'ingénierie.
Directeur du groupe de recherche sur les réseaux et les systèmes. Université de Deusto.
Pour plus d'informations ou un devis
