starbuck - 25.07.2015 | 2 réactions | #link | rss
Mardi dernier, Andy Greenberg, journaliste pour le magazine Wired, publiait son retour d'expérience particulièrement effrayant sur le piratage à distance d'une Jeep du constructeur Chrysler.
lire la suite »
starbuck - 29.12.2010 | 1 réactions | #link | rss
Une difficulté souvent rencontrée dans le cadre d'analyses de risques de sécurité logicielle, telles que les tests d'intrusion, est la qualification précise de la menace induite par la présence d'une vulnérabilité.

Comment justifier dès lors les coûts induits par la correction immédiate d'une vulnérabilité logicielle? Faut-il repousser une mise en production? Faut-il au contraire la maintenir tout en planifiant la correction du logiciel? Comment justifier ces choix lorsque l'on se trouve en situation de prestataire externe, ou en interne lorsque l'on est le garant de l'assurance sécurité du S.I.?


Contexte


De nombreux analystes fondent actuellement leurs recommandations sur une "recette maison" combinant à la fois des éléments issus de référentiels externes, tels que le Top 10 des risques de sécurité des applications web ou encore le Top 25 des erreurs de programmation favorisant des brèches de sécurité, et des éléments issus de l'expérience personnelle, tels que traditionnel "death wish" matérialisé par la présence d'une injection SQL dans une application.

Le résultat est palpable par les clients consommateurs de prestation d'analyse de risque: une vulnérabilité identifié par la société A au sein d'un logiciel donné ne sera pas qualifiée de la même façon lorsque la société B effectuera à son tour une évaluation.

Ces divergences peuvent alors entraîner des erreurs d'appréciation dans la définition des priorités et exposer des systèmes d'information de toutes sortes à des attaques informatiques au risque mal- ou sous-évalué.


A qui la faute?


Les prestataires de services sont-ils en cause? Ou faut-il plutôt accuser leurs clients?

La sécurité logicielle est encore une démarche plus artistique que scientifique qu'il s'agisse de la modélisation des menaces, la sélection des tests techniques, la documentation des vulnérabilités ou de l'évaluation du risque local ou global. Chacune de ces activités est aujourd'hui couverte par un ou plusieurs référentiels. Certains sont réputés adoptés par d'importants acteurs économiques, tels que la Testing Methodology de l'OWASP pour les applicatifs web, mais ces modèles n'ont pas encore eu le temps de faire leurs preuves: on ne sait pas s'ils fonctionnent réellement.

Pour la qualification du risque, sujet qui nous intéresse plus particulièrement, les alternatives sont réduites dès que l'on souhaite faire appel à un model un tant soit peu scientifique (mesure de valeurs discrètes et application d'une formule mathématique pour calculer un indice).

L'OWASP propose par exemple la Risk Rating Methodology, peu remise en question, peut-être parce que peu d'analystes la connaissent. De son côté, Microsoft a publié en 2008 la Microsoft Exploitability Index, mais la méthode souffre d'un rejet pseudo-allergique par la communauté. La société Cenzic, propriétaire du scanner de vulnérabilités Hailstorm, a proposé la méthode HARM mais la pilule n'a probablement pas bien passé au sein d'un marché ultra-concurrentiel. Le CERT/SEI s'appuye sur la méthode FMECA pour qualifier les failles mais l'outil n'a pas réussi à sortir du monde "langage C" et l'institut MITRE a publié le modèle OVAL (Open Vulnerability Assessment Language) visant entre autres à rendre les autre modèles interopérables.

Bien qu'il s'agisse de méthodes rodées, elles restent méconnues (en raison d'un marketing plus que dérisoire) et peu soutenues d'un point de vue quantitatif: les données révélant l'éventuelle efficacité ou inefficacité de ces modèles sont difficiles à trouver.

D'un point de vue réglementaire, c'est également la jungle. Aucune Loi ne contraint le prestataire d'un test d'intrusion à se conformer à un modèle d'analyse particulier. Il en résulte généralement des indices "faits maison" et qu'il sera parfois difficile de justifier si l'on doit présenter les conclusions d'un rapport recommandant des investissements urgents de près de 500'000 francs devant un comité de direction.

Finalement, le cas des missions de tests d'intrusion logicielle (applications web, services, desktop, etc.) est révélateur de la jeunesse de ce marché. Nombreuses sont les entreprises qui aiment par exemple procéder à la rotation annuelle ou bisannuelle de leurs prestataires d'analyse de risques en sécurité sans pour autant leur communiquer un référentiel commun ou standard sur lequel s'appuyer soit pour conduire les tests, soit pour qualifier les risques. Dès lors, comment savoir qu'un prestataire exécutera au moins, si ce n'est plus, les mêmes contrôles que le prestataire de l'année précédente? L'on constate ainsi que cette approche initialement dopée par des considérations défensives perd rapidement de son efficacité dès que l'on considère le processus dans la longueur, à l'échelle de plusieurs années.


CVSS: insuffisant!


L'institut FIRST, auteur de la méthode CVSS (Common Vulnerability Scoring System) a adapté son modèle pour la seconde et dernière fois en 2007. CVSSv2 est ainsi devenu un modèle au sein de nombreuses organisations et outils de sécurité et fait aujourd'hui office de standard pour l'évaluation des vulnérabilités IT.

Toutefois, les éléments composant la formule de calcul du score CVSSv2 ne prennent pas en compte des facteurs intrinsèques aux vulnérabilités logicielles, tels que:
  • L'importance d'une distinction claire entre la probabilité d'une exploitation, la prévalence d'une faille dans le code et l'impact différentiel résultant des deux évaluations respectives.
  • Certains indicateurs tels que la distribution au sein du parc IT n'ont pas forcément leur place au sein d'une vue logicielle.
  • CVSSv2 ne prend pas en compte par défaut des modèles d'environnement de production aux besoins de sécurité spécifiques, tels que les applications financières, les installations sensibles (systèmes SCADA), les réseaux sociaux, les entrepôts de données personnelles, les e-commerces, etc.

Parallèlement, l'on constate une pression croissante des autorités de réglementation diverses. L'exemple des Etats-Unis est intéressant: le Cybersecurity Act of 2009 instruit au NIST (autorité chargée d'émettre les directives de sécurité des systèmes d'information publics et de la Défense) de mettre en oeuvre ou choisir un standard d'évaluation et de qualification du risque des vulnérabilités logicielles.


CWSS: la nouvelle Rolls-Royce?


Là où l'autorité NIST (National Institute of Standards for Technology) joue plutôt un rôle de sélectionneur de contrôles de sécurité à l'intention des systèmes du gouvernement américain, l'institut MITRE joue le rôle d'un définisseur de nouveaux modèles de contrôles basés sur la collaboration d'acteurs-clés de l'économie américaine.

A ce titre, le MITRE a débuté la mise en oeuvre du modèle CWSS (Common Weakness Scoring System). CWSS a pour objectif d'apporter au monde de la sécurité logicielle un outil équivalent à CVSS dans le domaine IT.


4 méthodes de calcul

CWSS propose 4 méthodes pour le calcul de l'importance des vulnérabilités logicielles:
  • Formule ciblée (Targeted method)
  • Formule généralisée (Generalized method)
  • Formule contextualisée (Context-adjusted method)
  • Formule agrégée (Aggregated method)

La méthode de calcul ciblé (targeted method) s'adresse aux professionnels de la sécurité souhaitant qualifier une vulnérabilité précise identifiée au sein du logiciel évalué. Elle est également applicable par les outils d'analyse automatisée.

La méthode de calcul généralisé (generalized method) a pour objectif la qualification d'un groupe de vulnérabilités d'un même type, pris en compte à l'échelle logicielle globale et non plus au sein d'un produit particulier. Cette méthode sera particulièrement applicable dans le cadre de définition de référentiels de risques, tels que le Top 10 de l'OWASP ou tout autre référentiel de risque créé en interne au sein d'une organisation.

La méthode de calcul contextualisé (Context-adjusted method) a pour objectif d'abaisser ou augmenter l'importance d'une vulnérabilité en fonction de l'environnement dans lequel elle a été identifiée. Grâce au modèle des vignettes (expliqué plus bas), cette méthode permet la prise en compte de priorités/risques supérieurs selon le type d'organisation et d'environnement dans lequel se trouve le logiciel. A titre d'exemple, une vulnérabilité pouvant provoquer une paralysie partielle ou complète d'un service sera pondérée vers le haut dans un environnement de type e-commerce et vers le bas dans le cas d'un extranet de gestion de ressources humaines.

La méthode de calcul agrégé (Aggregated method) a pour objectif de permettre le calcul de l'importance résultant de la prise en compte combinée de plusieurs vulnérabilités d'importance variable. Selon la stratégie de calcul choisie (maillon faible, maillon fort, moyenne pondérée, etc.), l'importance finale pourra être revue à la baisse ou à la hausse.


Les vignettes

CWSS apporte un élément particulièrement important et absent dans la majorité des méthodes citées en début d'article: la possibilité d'appliquer de manière transversale un modèle de risque spécifique à l'organisation ou un élément de l'organisation.

Pour mieux comprendre ces vignettes, le modèle en cours d'évaluation comprend par défaut 5 vignettes:
  • Logiciels à forte composante "commerce" (e-commerces)
  • Logiciels à forte composante "finance/transactions" (banque, courtage)
  • Logiciels à forte composante "infrastructures critiques" (systèmes SCADA)
  • Logiciels à forte composante "données personnelles"
  • Logiciels à forte composante "réseaux sociaux"

Pour chacune de ces vignettes, un modèle de risque (priorités hautes, basses) a été défini sur la base de 15 impacts techniques en cas d'une exploitation de la vulnérabilité:
  • Modification arbitraire des données en mémoire
  • Accès arbitraire aux données en mémoire
  • Modification arbitraire des fichiers
  • Accès arbitraire aux fichiers
  • Modification arbitraire des données en base de données
  • Accès arbitraire aux données en base de données
  • Déni de service: arrêt du service
  • Déni de service: réduction de la capacité de traitement
  • Déni de service: instabilité
  • Déni de service: accès arbitraire aux unités de calcul
  • Déni de service: accès arbitraire aux ressources de stockage
  • Exécution de code arbitraire
  • Elévation de privilèges, usurpation d'identité
  • Contournement des mécanismes de détection d'intrusion
  • Répudiation des actions (invalidation des pièces légales)

Le modèle proposé décrit ainsi la gravité de chacun des 15 types d'impact techniques au sein des 5 environnements (vignettes) inclus par défaut dans le modèle de calcul.


Les facteurs de calcul pour la méthode de calcul ciblé (Targeted)

Dans le cadre des calculs d'index pour une vulnérabilité ciblée, les éléments suivants sont pour l'instant retenus dans la formule:
  • Accessibilité de la vulnérabilité:
    • Localisation (conditions d'accès au code vulnérable)
    • Diffusion dans toutes les installations
    • Diffusion selon les versions
    • Diffusion selon les configurations
  • Exploitabilité de la vulnérabilité:
    • Niveau d'exploitabilité (attaque pratique, démontrée, théorique)
    • Efficacité des mesures de sécurité périmétrique
    • Efficacité des mesures de sécurité intrinsèque (validation de données en couches)
    • Popularité de la vulnérabilité
    • Popularité de la méthode d'identification de la vulnérabilité
  • Autres facteurs:
    • Coût d'une éventuelle correction
    • Niveau de confiance accordé à l'annonce de la présence de vulnérabilité
      • Vérifiée
      • Non vérifiée
      • Identifiée par un humain
      • Identifiée par un logiciel
    • Dommages collatéraux
      • Financiers, physiques (sûreté), données personnelles, utilisateurs (systèmes), utilisateurs (humains)
    • Priorités de l'organisation (confidentialité, intégrité, disponibilité)
    • Stratégie de réduction de risques
      • Par niveau de risque plafond
      • Par niveau de risque plancher
      • Selon norme/réglementation/standard en vigueur
      • Par coût
      • Par prévalence

Calcul du score CWSS

Le calcul final de l'indice est construit sur la base d'une multiplication finale simple:
Prévalence x Importance

L'indice de prévalence est un nombre compris entre 1 et 10, obtenu de l'extérieur du système évalué sur la base de sa typologie d'architecture (application embarquée, logiciel client-serveur, application web, etc.).

L'indice d'importance est un nombre compris entre 1 et 10, construit sur la base des impacts définis dans la vignette retenue et du type de la vulnérabilité identifiée.

Le score final est un nombre compris entre 1 et 100, représentant l'index de risque de la vulnérabilité. Plus ce nombre est haut, plus elle doit être considérée comme prioritaire dans le cadre d'un plan correctif.


Conclusion


D'un point de vue local, CWSS propose deux avancées majeures dans la qualification des risques induits par les vulnérabilités logicielles.
En premier lieu, CWSS intègre directement la base de données de vulnérabilités logicielles CWE (Common Weakness Enumeration) établie par MITRE.

Cette compatibilité assure un accès rapide à la description technique et formalisée d'une vulnérabilité, de ses éléments associés/parents/enfants ainsi que des mesures à mettre en oeuvre pour en assurer la protection ou faciliter la détection automatisée.

Deuxièmement, en intégrant le concept des vignettes, CWSS s'aligne avec les méthodologies de modélisation de risques (Threat Modeling) en intégrant la prioritisation des risques selon les attentes de la Direction d'une organisation. D'une part, ces vignettes peuvent être définies une fois pour toutes à l'échelle de l'organisation ou de ses unités métier avant d'être utilisées par les différents prestataires de services de sécurité. D'autre part, les vignettes vont permettre un meilleur traitement des risques dans la mesure où elles seront le résultat d'une analyse d'impacts.

D'un point de vue plus global, il n'est pas improbable que CWSS suive les traces de CVSS et devienne prochainement un standard dans la description et la qualification des vulnérabilités logicielles. Ceci permettra d'une part aux prestataires de s'appuyer sur des références de l'industrie pour leurs analyses, et d'autre part, de contraindre certains prestataires à émettre des analyses de sécurité moins alarmistes et plus compatibles avec les priorités spécifiques de leurs clients.

Finalement, CWSS est avant tout un outil de plus mis à disposition des garants de la sécurité de l'information au sein des entreprises: ils peuvent ainsi demander à leurs prestataires et fournisseurs de logiciels d'appliquer ce modèle au sein de leurs analyses afin de faciliter la consolidation des tableaux de bords de la sécurité logicielle sur le long terme.

Pour aller plus loin:
- Common weakness scoring system (MITRE.org)
- CWSS vignettes (MITRE.org)
- CVSSv2 history (FIRST.org)
- CVSSv2 index calculator (NIST.gov)
- S773 – Cybersecurity Act of 2009 (govtrack.us)
- OVAL - Open vulnerability assessment language (MITRE.org)
- Microsoft Exploitability index (microsoft.com)
Quelques réflexions indiscrètes sur les technologies de l'information, la mobilité, la protection des données personnelles


articles
réactions
FutureBlogs - v.0.8.6beta - Ce site est hébergé par http://monblog.ch