starbuck - 16.04.2012 | 21 réactions | #link | rss
J'ai eu la bonne idée ce weekend de réinstaller totalement mon téléphone portable. De temps en temps, je trouve bien de "repartir à zéro", surtout lorsqu'il s'agit d'un petit bout de technologie que l'on peut perdre ou oublier dans un lieu public et qu'il contient une immense quantité de données et d'accès à des services authentifiés.

L'on devinera bien entendu qu'il a fallu que je réinstalle toutes les applications qui me réchauffent quotidiennement le coeur lorsque je prends les transports publics ou que j'attends patiemment le long d'une file indienne. Cet article s'intéresse ainsi à l'émotion ressentie par l'une d'entre elles, Viber. Pour ceux qui ne la connaissent pas, c'est une alternative intéressante à Skype: envoi d'appels et messages par le canal data, cela fonctionne très bien et la qualité de voix est inégalée lorsque la connexion est établie via un réseau wifi. Je n'ai aucune dent particulière contre cette application (je la trouve d'ailleurs très utile et bien faite) mais, c'est la troisième à m'avoir un peu agacé par les interactions proposées.

Cela m'a convaincu de perdre 43 minutes de ma vie pour rédiger un billet sur ce sujet...
lire la suite »
starbuck - 21.11.2011 | 7 réactions | #link | rss
J'ai appris ce matin en lisant un journal, non sans une certaine joie, que le service de diffusion de musique en ligne Spotify a finalement été rendu disponible aux internautes suisses. Ni une ni trois, j'ai ouvert un onglet "www.spotify.ch" et j'ai cherché le lien d'inscription. Quelle joie de pouvoir enfin utiliser ce service en toute légalité! (comprenne qui pourra)

Enfin, quoique...
lire la suite »
starbuck - 25.07.2011 | 4 réactions | #link | rss
La société Imperva, s'étant déjà fait connaître au travers de plusieurs analyses de grands échantillons de données, a récemment publié les conclusions d'une analyse de plus de 10 millions de requêtes "hostiles".

La méthodologie reste simple sans pour autant être moins efficace: durant six mois, l'observatoire a placé des sondes de collecte de données sur une trentaine de sites web d'importance, secteur d'activité et notoriété variables. D'autres sondes ont également été placées sur plusieurs noeuds sortants du réseau TOR, l'un des réseaux d'anonymisation les plus utilisés par les pirates en recherche de failles de sécurité et souhaitant réduire les traces de leur visite.

Pour consulter le rapport dans son intégralité, c'est ici, pour le résumé, il suffit de lire la suite.
lire la suite »
starbuck - 28.02.2011 | 17 réactions | #link | rss

Quel compte est associé à quelle identité? Des messages d'erreur qui en disent plus qu'ils ne devraient


Une surprenante modification attendait cette semaine les utilisateurs possédant un compte sur la célèbre plateforme de consultation de vidéos en ligne. En effet, Google, qui en est l'actuel propriétaire, contraint désormais ses utilisateurs à migrer leur compte Youtube vers leur compte Google.
lire la suite »
starbuck - 21.01.2011 | 4 réactions | #link | rss


De nombreuses entreprises accédant à la Bourse européenne du carbone (European Emissions Trading System, EU ETS) ont été visées avant-hier par une attaque de type phishing qui a permis le détournement de plus de 28 millions d'euros.

La Commission européenne a prononcé l'arrêt immédiat des transactions sur la plateforme EU-ETS a immédiatement, le 19 janvier dernier, peu après avoir constaté l'attaque.
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)
starbuck - 19.04.2010 | 2 réactions | #link | rss
Au même titre que de nombreux amateurs de vin se réjouissent de leur nouveau Beaujolais, le monde de la sécurité logicielle attend avec impatience chaque nouvelle édition du Top 10 de l'OWASP, à savoir, le référentiel des dix risques de sécurité majeurs dans les applications web.

En effet, depuis un peu plus de deux années, le Top 10 de l'OWASP est passé d'un simple document de rappel pour les analystes en sécurité à un référentiel réputé et reconnu à l'échelle mondiale comme l'une des sélections les plus représentatives des risques de sécurité que l'on rencontre dans des applications web mal protégées contre les intrusions.

Cette édition 2010 se voit également beaucoup plus ambitieuse sur le plan de son adoption: il ne s'agit plus cette fois de la faire reconnaître au sein de la communauté mais de s'assurer que tout développeur web en prenne connaissance.

Après plus de trois mois de débats internes au sein de la fondation, les experts se sont finalement mis d'accord sur la sélection finale des dix risques et l'édition 2010 est dès aujourd'hui disponible en libre téléchargement sur le site officiel de l'OWASP.
lire la suite »
starbuck - 25.03.2010 | 4 réactions | #link | rss
Ça y est, c'est décidé, vous allez déléguer la gestion complète de certaines activités logicielles (conception, développement, déploiement, support, hébergement, maintenance) à un partenaire afin d'économiser des coûts. Salaires des collaborateurs, de leurs vacances, gestion électronique des documents, applications métier, tout sera en ligne afin d'économiser des coûts à tous les niveaux: infrastructure, ressources humaines, opérations, et j'en passe.

C'est le Software as a Service, le SaaS (ou l'ASP pour ceux qui ont compris qu'on n'a rien inventé mais que ça excite le marketing d'avoir de nouveaux mots) c'est certainement estampillé cloud computing, c'est tendance, c'est génial et ça le fait lorsque vous en parlez à d'autres directeurs!

Pourtant, vos données ne sont désormais plus chez vous. Elles sont ailleurs.

Où sont-elles? Qui les protège? Comment sont-elles protégées? Quelles sont les garanties de sécurité dont vous disposez? Les avez-vous contractualisées?

Pour vous aider à gérer ces risques, vous trouverez ci-après une liste de points de contrôles à valider en amont de la conclusion d'un accord avec votre partenaire.
lire la suite »
starbuck - 23.02.2010 | 1 réactions | #link | rss
La nouvelle édition du Top 25 Most Dangerous Programing errors, un référentiel des 25 erreurs de développement à la source des plus graves faiblesses de sécurité logicielle, est en ligne.
lire la suite »
starbuck - 23.02.2010 | 1 réactions | #link | rss
Le DISA (Agence américaine chargée de la gestion des systèmes d'information de la défense) a déclassé un protocole complet destiné à standardiser les activités d'audit de sécurité sur les logiciels acquis ou développés au sein du département de la défense.
lire la suite »
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