Catégorie : Méthodologie

Saga de l’audiovisuel

• Présentation et enjeux du test
• Tests fonctionnels
• Stress, Endurance, Performance
• Et l’automatisation alors ?

Pourquoi automatiser ?

Bienvenue à nouveau dans le monde de l’audiovisuel. Nous avons évoqué les enjeux du test en télévision numérique, ainsi que les différents types de test et leur protocoles. Abordons maintenant le sujet de l’automatisation.

Les pauvres testeurs ! On trouvait ça cool nous, d’être payé à regarder la télé derrière son bureau, mais en fait c’est dur comme boulot !

Exactement, c’est pas tous les jours facile la vie de testeur dans l’audiovisuel, beaucoup de tâches répétitives, j’appuie sur la touche menu, j’observe, je mesure, et à la longue, la concentration diminue, et le risque d’erreur, de passer à côté d’une anomalie augmente.

D’autre part, durant les longues phases de test d’endurance, le testeur connaît l’état de son décodeur au lancement du test, puis à l’issue du test, mais comment savoir s’il n’y a pas eu d’erreur pendant le test, un redémarrage imprévu après lequel la set top box s’est remise sur pied d’elle même, des problèmes de qualité audio/video, un message d’erreur temporaire,…

Certains problèmes, comme un redémarrage du décodeur, peuvent-être détectés en “instrumentant” un décodeur en test, c’est-à-dire, en récupérant les logs ou traces de l’application, mais cette solution a le défaut d’influer sur les performance du décodeur, et ne reproduit pas fidèlement le comportement d’un décodeur sur le terrain qui eux sont configurés pour ne plus produire de logs.

Robots de test

Oyez, testeurs, vous n’êtes pas seuls. Quelques sociétés du secteur informatique et télécommunication, Sopra, S3 TV Technology (racheté par Accenture), ou encore Witbe on mis au point des solutions d’automatisation des test pour la télévision numérique.

Le rôle de ces équipements, ou robots de test, est de reproduire les actions d’un utilisateur réel et d’analyser les comportements du matériel testé.

Pour ce faire, un robot possède des “mains”, ou plutôt un émetteur infrarouge (ou bluetooth ou RF) contrôlable avec lequel il peut envoyer des commande au décodeur. Il possède également des “yeux”, une carte d’acquisition vidéo lui permettant de visualiser la sortie vidéo du décodeur, des “oreilles”, une carte d’acquisition audio pour récupérer la sortie audio, et pour gérer tout ça, un cerveau rapide et puissant, composé d’un processeur, de beaucoup de mémoire vive et d’algorithmes complexes lui permettant par exemple :

• De reconnaître des images spécifiques : message d’erreur, mogo de démarrage, bannière information, ou toute autre image fixe pouvant être vue par un humain
• De reconnaître des caractères (OCR) : numéro de chaîne, nom du programme en cours
• De mesurer le volume audio et inversement de détecter une absence de son ou un niveau anormal
• De détecter une image figée non prévue
• De détecter un écran noir

Voici un schéma explicatif d’un environnement de test automatisé au moyen d’un robot de test :

 

La combinaison de toutes les fonctionnalités décrites ci-dessus, offre aux robot de test, la possibilité d’effectuer des tâches répétives et complexes de navigation, de reconnaissance des menus affichés, des mesures précises des temps de zapping ou encore de démarrage.

Les robots n’ont pas besoin de sommeil, ainsi, il peuvent observer, détecter et enregistrer toutes les anomalies survenant jour et nuit ce qui, comme nous l’avons vu précédemment peut s’avérer très utile lors des tests d’endurance.

Les robots possèdent également des capacités d’analyse de la qualité audio/vidéo (QoE pour Quality of Experience). Ils sont notamment capables de détecter des “artefacts”, qui sont des défauts de qualité comme la présence de courts écrans noirs, ou encore de macroblocs (présence de carrés anormaux sur l’image, comme quand vous regardez un film en streaming et que soudain, votre débit internet diminue, vous entendez alors des bruits étranges, les glitchs audio, et votre image se dégrade, devient, rouge, verte, violette avec pleins de carrés, comme si l’image se pixelisait.

Enfin, les capacités de reconnaissance d’image des robots permettent également de faire de la supervision afin de connaitre en temps réel la disponibilité des services vidéo (QoS pour Quality of Services) délivrés. Ce sujet s’écarte de la pure problématique qualité d’un décodeur numérique, et touche à la diffusion des programme vidéos (broadcasting). Nous y reviendrons sûrement dans un autre article.

Hommes de test

Ah on est rassurés, on ne leur demande pas d’appuyer 100 000 fois sur une touche de leur télécommande. Mais ils ne risquent pas de se faire virer si des machines peuvent faire leur travail à leur place ?

Aucune chance, et gare à celui qui viserait cet objectif. Les robots n’ont pas de perte de concentration, sont insomniaques et sont des bourreaux de travail, mais ils ont un point faible, ils ont besoin de l’Homme pour savoir quoi faire, comment le faire et pour comprendre leur langage. Ces deux là sont totalement complémentaires, symbiotiques. Les robots soulagent les testeurs en prenant en charge les tâches longues et répétitives, les testeurs, en échange les entretiennent, les optimisent, et interprètes les données qu’ils fournissent.

Le plus souvent, lorsque qu’un robot est déployé, là où il n’y avait qu’un testeur, il y a maintenant, en plus, un responsable d’exploitation chargé de l’infrastructure, de la rédaction et de la maintenance des scripts de tests.

Et côté ROI, pas d’inquiétude non plus, c’est tout de même l’un des interêts, une gestion automatisée des tests augmentera la capacité de l’équipe et la fiabilité des tests, diminuant significativement les coûts de non qualité.

Conclusion

Si nous avions un conseil à vous donner, n’ayez pas peur d’automatiser ! Que ce soit en confiance, en fiabilité, en couverture, en rapidité, vous y gagnerez. Et si nous avions un second conseil à vous donner, automatisez intelligemment ! Toutes les solutions existantes ne vous sont pas forcément nécéssaires. Prenez le soin et le temps d’étudier votre besoin et les compétences de vos équipes avant de vous jeter sur la solution la plus attirante ou la moins chère. A titre d’exemple, il vaut peut-être mieux investir dans une solution plus coûteuse mais pour laquelle l’écriture des scripts se fait dans un langage de programmation déjà connu de vos équipes. Bonne automatisation !

Découvrez nos autres séries d’articles !

Notre série dédiée aux tests de sécurité

Celle dédiée à Protractor

Le kit de secours métaphorique du testeur agile

Saga de l’audiovisuel

• Présentation et enjeux du test
• Tests fonctionnels
• Stress, Endurance, Performance
• Et l’automatisation alors ?

Les tests non fonctionnels

De retour sur nos petits écrans, pour découvrir maintenant de quelle façon sont testés les aspects non fonctionnels de notre décodeur numérique.

Eh oui, notre équipement doit savoir afficher une chaine de télévision, il doit comprendre quand nous lui donnons un ordre avec notre télécommande, mais il doit être aussi capable de le faire vite, et de le faire bien.

On lui en demande beaucoup à cette pauvre petite boîte éléctronique.

C’est vrai, les testeurs ne sont pas toujours tendres avec leur décodeurs, mais c’est pour la bonne cause.

Tests d’endurance et stress tests

Dans cette catégorie, on ne teste plus les fonctionnalités à proprement parler du décodeur, mais la résistance du système lors de l’exécution prolongée d’une action ou de la répétition d’une action sur une longue durée.

On parlera d’endurance lorsque la charge imposée au système est relativement faible, et de stress lorsque celle-ci est importante au sens de la consommation de ressources.

Live statique

Ce test, d’endurance uniquement, consiste à laisser le décodeur jouer une chaîne en continu (la veille automatique doit être désactivée), et de vérifier que la chaîne continue d’être diffusée sur la durée spécifiée. Les exigences sur cette durée sont variables selon les fabricants, les décodeurs mais aussi en fonction de la catégorie de chaîne que l’on test. En effet, nous pourrons distinguer entre autres les cas suivants avec une consommation de ressources croissante :

• Chaîne SD (Standard Definition) non cryptée (gratuite)
• Chaîne SD cryptée (nécessitant un abonnement)
• Chaîne HD (High Definition) non cryptée
• Chaîne HD cryptée
• Chaîne HD cryptée, avec enregistrement d’un programme sur une autre chaîne et timeshift sur la chaîne en cours

Plus la charge augmente, moins la durée exigée est longue. Par expérience, un décodeur devrait pouvoir jouer en continu un programme SD pendant 7 jours en continu sans rencontrer de problèmes, mais dans la pratique ce n’est pas toujours le cas et parmi les problèmes rencontrés par les équipes de validation, entre autre, freeze (image figée), redémarrage spontané, écran noir…

Le protocole ici est on ne peut plus simple, on démarre un ensemble de décodeurs sur la/les chaînes souhaitées en vérifiant l’image et l’audio, on vit sa vie sans y penser pendant la durée exigée, puis “on relève le mur”, c’est à dire, qu’on constate l’état des décodeurs à l’issue de cette durée, nombre de OK, nombre de KO, description des KO. Dans la pratique, on vient jeter un œil tous les jours ou plus sur les décodeurs, car s’ils sont tous plantés après 20 minutes, aucun intérêt de poursuivre le test.

AC On / Off

Ici même principe de tenue du système dans la durée, mais l’action est plus agressive. Il s’agit de répéter la séquence : coupure d’alimentation / mise sous tension. En endurance, des séquences répétées de 10 minutes laissent normalement le temps à tous les décodeurs de finaliser leur séquence de démarrage. En stress, les séquences peuvent être très courtes de l’ordre d’une minute. L’intérêt étant de pouvoir valider le comportement du système lors de l’arrêt brutal des processus en court.

Ce test est stressant pour le software et le hardware, mais permet de détecter des défauts lors de la séquence de boot (démarrage) et d’évaluer la probabilité qu’une coupure de courant en utilisation terrain (sur le meuble télé du client) puisse entraîner une anomalie.

Zapping

Qu’est-ce qu’un zapping ? Ça ne sonne pas très scientifique ce mot. Un zapping est un changement de chaîne. Déclenché par l’utilisateur muni de sa télécommande, il s’agit de l’action la plus courante que doit effectuer un décodeur numérique. Il existe beaucoup de “zappings” différents :

• Par appui sur la touche chaîne suivante, (P+ ou Next Channel pour les intimes) 
• Par appui sur la touche chaîne précédente, (P- ou Prev Channel pour les intimes) 
• Par navigation dans l’EPG (Grille des programmes ou Electronic Program Guide pour les intimes)
• D’une chaîne SD à une chaîne HD et inversement
• D’une chaîne cryptée à une chaine non cryptée et inversement
• Avec un enregistrement en cours
• Avec la fonctionnalité Pip (Picture in Picture qui consiste à afficher une autre chaîne que celle en cours dans un cadre)
• …

Tous ces zappings font appels à des fonctionnalités différentes et ont donc des comportements différents qui doivent être validés. L’action de zapping peut sembler anodine, mais est en réalité assez complexe, et mobilise également beaucoup de ressources au système.  Le schéma suivant illustre les actions mises en œuvre par le décodeur lors d’un changement de chaîne classique (P+) :

• t1 : Temps d’apparition de la bannière d’information (info banner) ta : Temps d’apparition de l’écran noir de transition
• t2 : Durée de l’écran noir de transition
• tb : Durée d’affichage de l’info banner
• Temps de zapping = ta + t3 , c’est à dire le temps écoulé entre l’envoi effectif de la commande de changement de chaîne par l’utilisateur et la lecture de la chaîne demandée.

 

Que l’info banner soit présente à l’écran ou non, on considère le zapping effectif dès que l’audio et la vidéo de la nouvelle chaîne sont joués. Le test de la fonctionnalité zapping est effectué au moyen de boîtiers infrarouges (certains sont maintenant bluetooth ou RF) programmables (voir Redrat ou encore IRTrans).

De la même manière qu’en live statique, le testeur programme sa télécommande pour répéter l’envoi de la commande de changement de chaîne à intervalle régulier sur une période donnée, puis vient relever l’état du mur de test à l’issue de la campagne (nombre de décodeurs toujours en zapping, nombre de décodeurs ayant rencontré un problème et description du problème).

Pour se faire une idée, en endurance, un intervalle entre deux demandes de zapping de l’ordre de 15 à 20 secondes est une valeur acceptable afin de laisser le temps au décodeur de déclencher puis de stopper l’ensemble des processus associés, le décodeur pouvant supporter cette charge sur de longues périodes (une à plusieurs semaines).

En stress, cette durée est réduite à environ 5 secondes. A cette cadence, le décodeur n’a pas le temps de charger tous les processus avant de devoir les stopper pour répondre à l’ordre suivant. Il est fréquent lors de ce stress test de voir des décodeurs échouer au bout de quelques heures seulement. Ce test est intéressant car il permet de simuler et d’analyser le comportement d’un décodeur par exemple lorsque l’utilisateur s’endort sur sa télécommande. Dans cette situation, le fabricant doit s’assurer que le système tienne la charge, ou à défaut qu’un redémarrage suffise à le relancer.

Tests de performance

Dans le cadre de la validation d’un décodeur numérique, il est intéressant de mesurer différents temps d’action du système selon les fonctionnalités demandées et de s’assurer qu’elles restent dans des seuils acceptables par utilisateur. Parmi ces mesures, on notera les :

Temps de zapping

Comme nous l’avons vu précédemment, la mesure s’effectue entre l’envoi de la commande par l’utilisateur et l’apparition (audio/vidéo) de la chaîne demandée. Pour effectuer cette mesure, le testeur calcule généralement une moyenne à partir d’un échantillon d’une dizaine de mesures effectuée manuellement. Il est difficile de fournir un critère d’acceptation général pour le temps de zapping tant les durées peuvent varier selon les produits et les fonctionnalités activées.

Temps de Boot / Veille

Ici même principe, on ne cherche plus la tenue dans la durée, mais “simplement” à mesurer les durées des différentes étapes de la sortie de veille, ou de la remise sous tension. Comme pour les temps de zapping, le testeur est à son bureau, devant son décodeur et sa télé et son chronomètre. Il démarre son chronomètre au moment précis où il remet le courant dans le décodeur, ou appuie sur le bouton “On”, puis marque différents checkpoints temporels à des moments précis tels que : 

• L’apparition du message “Démarrage en cours” sur le front panel (l’écran à affichage digital dont tous les décodeurs sont munis en façade)
• L’apparition du logo sur le téléviseur
• L’apparition du menu principal ou diffusion de l’audio et de la vidéo d’une chaîne.

Ces mesures sont également moyennées sur des échantillons d’une dizaine de mesures.

Conclusion

Une nouvelle fois, cette liste n’est pas exhaustive. Comme pour les test fonctionnels, beaucoup d’autres tests non fonctionnels et mesures de performances sont possibles, comme le chargement et la navigation dans les menus, chargement et navigation dans la grille des programmes, chargement et navigation dans le menu VOD (vidéo à la demande),…

Le but de ces tests est en quelque sorte de s’assurer que votre décodeur résistera à toutes ou, presque toutes les misères que vous pourriez lui faire subir.

Le dernier article de la saga traitera le sujet de l’automatisation des tests en télévision numérique.

Saga de l’audiovisuel

• Présentation et enjeux du test
• Tests fonctionnels
• Stress, Endurance, Performance
• Et l’automatisation alors ?

Introduction

Les R&Ds des fabricants de décodeurs numériques possèdent une équipe de validation, dédiée à la vérification du bon fonctionnement des produits avant et pendant leur mise en production mais également après, lors des phases de maintenance.

Un bureau de validation de décodeur numérique est généralement un grand open space, rempli de câbles et d’ordinateurs, jusqu’ici rien d’anormal. Mais ils contiennent également un grand nombre d’équipements audio/vidéo splitter (genre de multiprise pour câbles d’antennes, ou câbles vidéo), de un à 4 téléviseurs directement posés sur les bureaux des testeurs, des décodeurs et leur télécommandes partout et mêmes des murs de tests, sortes de grandes colonnes sur lesquels sont montés 4 téléviseurs et munis de plateaux sur lesquels reposent, devinez quoi ?… Et oui, d’autre décodeurs numériques bien sûr.

Au quotidien, dans ces bureaux, les téléviseurs fonctionnent en permanence, affichant des programmes de tous les pays du monde, des films, les infos, les programmes des chaines musicales, et il n’est pas rare de croiser des testeurs, statiques devant une ou plusieurs télé, une télécommande à la main. Ne vous méprenez pas, cette personne travaille, et une partie de son travail consiste précisément à regarder la télé.

Ouah mais c’est trop bien, je veux faire le même travail !!!

Ne vous emballez pas, leur tâche est plus complexe qu’il n’y paraît. Lorsqu’ils semblent se relaxer devant un film récent, ils sont en réalité en pleine concentration, suivant un protocole de test précis, relevant dans le détail les observations qu’ils font sur le comportement du décodeur, suite aux commandes qu’ils lui ont envoyées au cours du test.

Voici quelques exemples de tests fréquents qu’ils peuvent être amenés à effectuer.

Tests fonctionnels

CAS, ou Conditionnal Access System

Outre le décodage du son et de l’image, fonctions principales du décodeur numérique, de nombreuses fonctions secondaires existent, et parmi elles, le CAS pour Conditionnal Access System.

Comme son nom l’indique, la mission du CAS est de contrôler l’accès des utilisateurs à certains programmes en fonction de leur contenu et du contrat souscrit par l’abonné. Je suis abonné à Sci-Fy, ma carte d’abonné le sait et autorise mon décodeur à afficher la chaîne. La plupart des décodeurs câble, satellite ou TNT (le cas des décodeurs IPTV est un peu différent) possèdent une fente destiné à l’insertion d’une carte puce, la smartcard. Il s’agit de votre carte abonné, permettant de d’identifier votre compte et toutes les chaines auxquelles vous avez souscrit. Ainsi pour tester le CAS, le testeur doit par exemple :

• Vérifier avec plusieurs cartes possédants des droits différents, que seules les chaines payantes souscrites et les gratuites sont accessibles, les autres devant afficher un message permettant de s’abonner.
• Insérer / Retirer plusieurs fois la smartcard du décodeur, et vérifier qu’à chaque insertion, la chaîne payante souscrite s’affiche, puis disparaît lors du retrait de la carte.

Contrôle parental

Houlalala, que c’est important, nous l’avons vu un peu plus tôt. La vérification du contrôle parental est capitale, on ne veut surtout pas que le Conseil Supérieur de l’Audiovisuel (CSA) nous tombe dessus !

Les tests associés sont assez amusants (en tout cas, je les trouve amusants…). Pour les voir en cours d’exécution, le mieux est d’être matinal.

Une explication s’impose. Pour tester le contrôle parental, il faut tout d’abord le configurer, c’est à dire saisir un code parental sur le décodeur en précisant le type de contenu protégé par mot de passe, violence, horreur, contenu adulte,…

Ce type de film étant généralement diffusé en dehors des heures de travail, le testeur peut par exemple programmer l’enregistrement, pendant la nuit, de programmes sensibles.

Le lendemain, il revient travailler, se place en face de son mur de test, devant ses quatre téléviseurs, et joue les enregistrements effectués durant la nuit. Objectif, vérifier que chaque enregistrement exige bien la saisie du code parental avant de démarrer.

Le produit étant en cours de développement, il arrive souvent que la fonctionnalité ne soit pas 100% opérationnelle, ou que le testeur saisisse le code parental pour contrôler le bon affichage de la vidéo.

         Mais pourquoi il a dit qu’il fallait être matinal ?

Eh bien parce que certaines situations peuvent être quelques peu gênantes, quand par exemple, un de vos confrère a oublié d’éteindre l’ampli audio utilisé la veille sur le même mur vidéo, dans le cadre d’un test de volume, et que des sons d’un genre douteux résonnent soudain dans les couloirs de la R&D au lancement de vos enregistrements, attirant progressivement tous vos collègues derrière vous pour admirer vos qualités de testeur expérimenté.

C’est la raison pour laquelle il est parfois souhaitable d’effectuer ces tests avant l’arrivée de vos collaborateurs.

Redémarrage

Le test de redémarrage ou reboot, consiste à démarrer un décodeur, s’assurer qu’il a terminé son démarrage, qu’il affiche soit le menu principal, soit une chaîne de télévision, puis de débrancher et rebrancher le cordon d’alimentation afin d’observer le comportement lors de la séquence de démarrage.

Ce test est très intéressant car durant cette phase de fonctionnement, le décodeur active un grand nombre de processus ce qui est très consommateur de ressources. Identification de version du firmware, recherche de nouvelles versions, téléchargement/installation le cas échéant, chargement et démarrage de l’application, démodulation, décodage du flux audio / vidéo, récupération des données de l’EPG… et j’en passe. Comme pour tout système embarqué, la gestion des ressources est un élément important pour lequel le test est indispensable.

Conclusion

Il existe une multitude d’autres tests fonctionnels, le timeshifting, les enregistrements, la VoD, le zapping, etc… Le but de cet article n’est pas de tous les décrire, mais de donner une idée du type de test pouvant être menés sur un applicatif de décodeur numérique.

Dans le prochain épisode de la saga de l’audiovisuel, nous aborderons le sujet des tests non fonctionnels en télévision numérique.

Saga de l’audiovisuel

• Présentation et enjeux du test
• Tests fonctionnels
• Stress, Endurance, Performance
• Et l’automatisation alors ?

Présentation du test audiovisuel

“Et voici la couleur, au jour fixé et à l’heure dite…”

Déclarait solennellement et avec fierté, Georges Gorces, alors ministre de l’information, le 1er Octobre 1967 à 14h15, à l’occasion de cette prouesse technologique que fut l’arrivée de la couleur sur nos petits écrans. Déclaration qu’il poursuivit par : “Vous cesserez très vite, je le sais bien, d’être sensibles à la magie de la chose.” Et il n’avait pas tort.

A l’époque, Huguette regarde tranquillement son épisode de chapeau melon et bottes de cuir sans se soucier de la qualité médiocre du son et de la vidéo, et demande simplement à René de taper 3 fois sur le poste de télévision lorsque la réception se dégrade. Notre attitude devant nos films et nos émissions préférés a bien changé. Ma vidéo est saccadée, j’appelle mon fournisseur d’accès internet, le son est mauvais, je renvoie ma télé chez Darty, un problème de réception satellite : “Allô Sky, je ne suis vraiment pas content”. Les évolutions technologiques en matière d’audiovisuel nous ont été offertes doucement, au fil du temps, augmentant insidieusement notre niveau d’exigence.

Pourtant, un simple coup d’œil 50 années en arrière permet de prendre conscience du chemin parcouru. Diffusion par câble, satellite et IP, télévision numérique, multiplication du nombre de chaines, qualité HD, Ultra HD, son Dolby Digital. En consommateurs exigeants que nous sommes, nous donnons toujours plus de fil à retordre aux industriels de l’audiovisuel, qui se doivent d’être irréprochables sur la qualité des services proposés, et qui dit qualité dit bien évidemment test. Cet article a donc pour objectif de présenter les méthodes et outils de test dans ce domaine bien particulier qu’est la télévision numérique. Bien que de nombreux types de tests existent dans cette industrie (Hardware, infrastructure, CEM, résistance au choc des décodeurs numériques, etc…), je vous propose de concentrer notre attention sur les tests logiciels d’un organe central de la télévision numérique, le décodeur.

 

Le décodeur numérique..

… ou STB (Set Top Box) pour les intimes, est partout,  dans votre salon, votre chambre, ou peut être votre cuisine. Depuis la disparition en France de la télévision analogique hertzienne le 29 Novembre 2011, cet appareil est nécessaire pour profiter des merveilleux programmes proposés par le service public et privés, et si quelques sceptiques se disent encore :

 

Mais il est fou, j’ai jamais acheté de décodeur moi, je ne sais même pas à quoi ça ressemble !

 

Je vous confirme que vous faites fausse route, votre décodeur est peut-être caché dans votre modem ADSL, votre télé ou encore votre tout nouveau lecteur Blu-ray, mais il est bel et bien là.

Le décodeur est un appareil électronique dont le rôle premier est de récupérer un signal numérique (flux) provenant de votre réseau câble, internet, Satellite ou TNT, puis de le convertir en signaux audio et vidéo pouvant être joués sur votre téléviseur.

Les décodeurs actuels possèdent de nombreuses fonctionnalités secondaires comme l’enregistrement de programmes, le timeshifting (possibilité de stopper, puis de reprendre un programme diffusé en direct), l’EPG (Electronic Program Guide) permettant d’afficher en temps réel des informations concernant les programmes en cours et à venir, et bien d’autres.

Un décodeur est constitué de différentes couches matérielles et logicielles, comme le décrit le schéma simplifié suivant :

• La couche Hardware : segment matériel du décodeur, il s’agit du circuit électronique sur lequel sont assemblés les différents composants électroniques de l’appareil (microprocesseur, démodulateur, convertisseurs CAN et CNA, …)
• La couche driver : fournit les briques logicielles nécessaires au pilotage des composants de la couche Hardware
• Le middleware : il s’agit de l’interface logicielle entre la couche driver et l’applicatif, ces deux dernières ne parlant pas le même langage, la fonction du middleware est donc de rendre possible la communication entre les drivers et l’applicatif
• L’applicatif : c’est l’interface utilisateur, celle que vous voyez au démarrage de votre décodeur, et avec laquelle l’utilisateur peut interagir via sa télécommande pour changer de programme, baisser le volume sonore ou bien démarrer l’enregistrement d’un programme.

Nous allons nous intéresser plus particulièrement à cette dernière couche, l’applicatif, celle avec laquelle notre utilisateur final, vous, moi, nous quoi, avons un contact direct.

 

Les enjeux du test en télévision numérique

Dans l’industrie audiovisuelle, minimiser la probabilité de présence d’une anomalie logicielle est essentiel.

En effet, un défaut matériel ou logiciel peut avoir un impact considérable tant sur le plan économique, qu’en termes d’image.

Un décodeur numérique est un produit grand public, et pour cette raison, il est produit et distribué en très grandes quantités, par millions. Comment réagiriez-vous en tant qu’utilisateur, tout content de déballer votre tout nouveau décodeur avec diffusion en 4k de MoMoMotus, si vous constatiez un problème lors de l’installation, ou des coupures de son répétées, pile sur les bonnes blagues de Thierry Beccaro ?  

Risques liés à la non qualité

Vous réagiriez très probablement comme des milliers d’autres déballeurs de décodeurs, par des appels répétés au service après vente. Ces appels, multipliés par le nombre important de clients insatisfaits mobilisent de nombreuses ressources, exigent un certain temps de traitement, notamment pour des problèmes complexes nécessitant un support de niveau 2.

Le traitement de ces milliers de cas clients représente un coût important pour l’opérateur. Il arrive également que les problèmes remontés par les clients à l’opérateur mette en évidence un défaut du produit. Dans ce cas, le fabricant doit mobiliser des équipes pour identifier et corriger l’anomalie, au détriment des autres projets en cours de développement. Ce genre de “crise” entraîne à son tour des coûts non négligeables et un risque de retard de livraison pour les autres projets.  

Risques de manquer une technologie

Cela peut encore aller plus loin, jusqu’au rappel des produits. Là, il ne s’agit plus seulement d’une histoire de coût mais également de la perte potentielle d’un marché au profit de vos féroces concurrents qui n’attendent qu’un faux pas de votre part pour s’approprier, à vos dépens, la place de leader de l’intégration de la toute dernière techno de compression audio ou vidéo dans leur terminaux résidentiels. Et il ne se privera pas d’en faire mention sur les salons, les forums hi-tech et autres réseaux sociaux.

Risques de dégradation de l’image de l’entreprise

Une autre fonctionnalité des décodeurs numériques est le contrôle parental. Souvent activé par défaut, il exige un mot de passe pour pouvoir jouer un programme au contenu interdit au mineurs, généralement des programmes contenant des scènes de violence ou de pornographie. Une défaillance du contrôle parental pourrait donc permettre à n’importe quel bambin jouant avec la télécommande de tomber sur un programme qui ne lui est pas destiné.

Ce genre de situation est bel et bien arrivé. Pas à ma connaissance sur les décodeurs numériques, mais dans le cadre de la diffusion de programme par internet (webTV) du groupe Canal+.

Ainsi le 15 Avril 2012, à 13h40, confortablement installés devant leur écrans, parents et enfant s’apprêtait à digérer leur repas dominical devant le dernier opus de la saga Arthur et Minimoys, de Luc Besson. Malheureusement, une défaillance technique sur les serveur de diffusion de la webTV a provoqué la diffusion accidentelle d’extraits de films pour adulte. Suite à cela, les abonnés concernés par le problème ont exprimé leur colère sur le forum du diffuseur, puis au tour des médias de s’emparer de l’affaire, RTL, Ouest-France, France tv info, … Compliqué pour le groupe de justifier un tel problème. La chaîne a dû présenter ses excuses aux abonnés tout en affirmant que la cause du problème avait été identifiée et ne se reproduirait plus.

En règle générale, ces risques sont connus, et bien que quelques rares problèmes passent les mailles des filets comme nous venons de le voir, de nombreux tests sont effectués dans l’industrie audiovisuelle afin de détecter et de corriger le maximum d’anomalies avant que les produits ne soient en utilisation chez les clients.

 

Conclusion

Les technologies de l’audiovisuel se sont démocratisées en quelques 50 années, et désormais, lorsque nous passons devant une nouvelle télévision 4K, ou un décodeur numérique dernier cri, cela semble banal. Il s’agit pourtant d’une industrie de pointe, en constante évolution, qui, à ce titre, nécessite une politique de test aux contours bien définis pour éviter entre autres, des catastrophes économiques et marketing.

Nous arborderons, dans le prochain article, le fonctionnement d’une cellule de validation pour décodeurs numériques ainsi que des exemples de tests courants. 

Le principe

Notre série d’article sur le défi de Ministry of Testing, 30 Days of Security Testing, se termine aujourd’hui avec un article dans lequel sont regroupé les défis qui permettent d’enrichir sa connaissance générale des tests de sécurité (actualités, aspects sociologiques, mises en application).

1. Compulser la documentation
2. Apprendre les bonnes pratiques
3. Découvrir les outils
4. Aller plus loin

Les challenges

Défi 10 : Comprendre ce qu’est l’« ethical hacking » & Défi 30 : Découvrir la différence entre les hackers black hat, white hat et grey hat

Pour rappel, en anglais « to hack » veut simplement dire « bidouiller », il n’y a pas de connotation négative en soi.

Alors que le hacker malveillant (ou black hat) tire profit des failles de sécurité à des fins personnelles, l’ethical hacker (ou white hat) les documente et propose des pistes afin de les solutionner. Il est en possession de toutes les autorisations nécessaires pour entrer dans le système à tester.

Comme vu précédemment, certaines entreprises embauchent des spécialistes en tests de sécurité (qui, par nature, sont des ethical hackers) afin de réaliser un audit. D’autres choisissent de récompenser les personnes qui leur rapportent bénévolement des failles de sécurité découvertes dans les limites de la légalité. Ces récompenses sont appelées « bounties ».

Si le hacker entre dans le système sans disposer des autorisations nécessaires, mais ne commet aucun acte malveillant, on parle de hacker « gray hat ». Des sites comme CVE Details (common vulnerabilities exposure) ou NVD (National Vulnerability Database) répertorient les failles de sécurité d’une multitude de produits.

L’imagerie populaire du hacker est déconcertante : nous serions tentés de croire que tous portent une capuche en permanence. En cause, une méconnaissance de l’activité de hacking, comme en témoigne cette interview d’un photographe de la banque d’images Shutterstock. Il serait pourtant utile que l’activité de hacking, de même que la sécurité informatique, soit mieux comprise, afin que chacun puisse mettre en oeuvre le nécessaire pour se protéger.

Défi 17 : Trouver une faille de sécurité récente

Lorsqu’une faille de sécurité est découverte dans un SI, volontairement ou non, le fait de la rapporter à l’organisation concernée sans exploiter la faille est appelé « disclosure ». Un acte bénévole dont il peut être risqué de parler, comme l’a montré en 2009 l’affaire Forever living products contre Zataz. Le fait de rendre une faille publique avant sa correction (chose que n’avait pas fait Zataz) est appelé « full disclosure ».

L’équipe Project Zero, qui regroupe sous l’égide de Google des spécialistes en sécurité informatique, a pour objectif de trouver des failles de sécurité « zero day », c’est-à-dire n’ayant jamais été exploitées. Leur ligne de conduite : informer immédiatement l’organisation responsable de l’application (disclosure), et ne procéder à une full disclosure qu’après que celle-ci a fourni un patch, ou au bout de 90 jours.

Le 25 novembre dernier, Google a informé Microsoft d’une faille de sécurité présente dans les navigateurs Internet Explorer et Edge. Malheureusement, Microsoft n’a pas été en mesure de fournir un patch dans les temps, et la faille est désormais publique et exploitable même dans la dernière version ! Voici son ticket d’anomalie.

Défi 20 : S’informer sur les attaques DOS/DDOS.

Une attaque DDOS (Distributed Denial Of Service) est une attaque visant à rendre indisponible un serveur. Son qualificatif « Distributed » est employé lorsque l’attaque provient de plusieurs machines différentes. Lorsque l’origine est une unique machine, on parle simplement d’attaque DOS.

On peut distinguer les attaques DDOS réseau et applicatives. Dans le premier cas, on sature la connexion réseau d’un serveur afin de le rendre incapable de répondre aux requêtes. Dans le second, après identification des actions de l’application qui demandent beaucoup de ressources (par exemple, des calculs impactant de nombreuses lignes en base de donnée), l’attaque consiste à les répéter jusqu’à saturation du serveur (source).

Un site web permet de visualiser sur une carte les récentes attaques DDOS.

Défi 23 : Quelles sont les 10 menaces de sécurité les plus courantes en 2016 ?

La liste des 10 failles de sécurité les plus courantes est éditée tous les trois ans par la fondation OWASP. La liste qui devait paraître en 2016 a été repoussée en 2017. L’équipe OWASP explique que le classement est resté sensiblement le même. Voici donc le classement de 2013.

Défi 26 : Comparer les tests de sécurité web et mobiles

Les tests à effectuer dépendent des menaces inhérentes à un système donné.

Certaines menaces sont propres aux applications web, comme les vulnérabilités liées aux cookies. Ces petits fichiers, stockés sur la machine cliente au cours de la navigation, qui contiennent des informations utiles : pages visitées, actions effectuées sur le site, mots de passe.

D’autres sont spécifiques aux applications mobiles, qui demandent des permissions susceptibles de compromettre les informations personnelles de l’utilisateur.

Mais les frontières des menaces tendent à se brouiller, notamment avec l’essor de frameworks tels que Cordova ou Ionic, qui permettent de développer des applications mobiles en se servant de technologies web. Les applications mobiles ne sont plus, logiquement, à l’abri des injections Javascript.

Défi 27 : Comment la tendance BYOA peut-elle affecter la sécurité ?

BYOA signifie « bring your own application » : cette tendance désigne par exemple les employés utilisant Google Docs avec leur compte personnel en lieu et place du SharePoint de leur entreprise. On parle aussi de shadow IT.

Plusieurs points peuvent être soulevés :

• En stockant des informations sur un outil tiers de son choix (souvent un cloud), l’utilisateur endosse la responsabilité de leur sécurité et devient en même temps dépendant du niveau de sécurité de l’application choisie. Un aspect que ni lui, ni son entreprise, ne maîtrisent. Un éditeur de bonne foi n’est pas à l’abris d’une fuite de données. En outre, l’utilisation des données stockées sur un outil tiers ne peut pas être entièrement maîtrisée.
• En cas de vol de son ordinateur, l’utilisateur est le seul à pouvoir mettre en oeuvre la protection de ses données (changement immédiat des mots de passe).
• En cas de vol d’identifiants, l’utilisateur n’a plus aucune prise sur l’utilisation du contenu qu’il a stocké sur un outil tiers.

Pour répondre à ces risques, certaines entreprises mettent en place une politique d’utilisation de logiciels tiers afin de sensibiliser aux menaces de cette tendance et de responsabiliser les employés.

Défi 28 : Partager des idées concernant les tests de sécurité dans un domaine particulier

Nous avons choisi de ne pas nous pencher sur un domaine en particulier, mais plutôt sur un type d’applicatif que nous utilisons quotidiennement : les logiciels open-source.

Logiquement, les failles d’un logiciel open source sont plus susceptibles d’être découvertes par le public que celles d’un logiciel propriétaire. Mais elles sont également plus susceptibles d’être révélées à son éditeur par la communauté, et donc plus vite corrigées. A contrario, les failles d’un logiciel propriétaires ne sont susceptibles d’être découvertes que par son éditeur lui-même, ou par les hackers black et grey hat. Les logiciels propriétaires ne sont pas à l’abris du reverse engineering, une pratique pourtant souvent interdite par les conditions générales d’utilisation.

Voici quelques articles ressources que nous avons trouvé sur le sujet :

• Is Open Source Software More Secure? de Russell Clarke et David Dorwin. Ce document donne une vue d’ensemble de la problématique
• Security Concerns in Using Open Source Software for Enterprise Requirements, de l’Institut SANS. Ce livre blanc fournit des bonnes pratiques afin de répondre aux enjeux spécifiques des logiciels open source dans l’entreprise.

… Défi 15 : S’exprimer sur les tests de sécurité sur les réseaux sociaux ou un blog

Voilà qui est fait. Déjà la fin des 28 jours de test de sécurité ! Si vous aussi avez participé au défi, laissez-nous un commentaire avec vos articles de blog, nous sommes curieux de les lire.

Découvrez nos autres séries d’articles !

Notre saga du test audiovisuel

Le kit de secours métaphorique du testeur agile

Notre série dédiée à Protractor

Le principe

Voici notre troisième article consacré au défi lancé par Ministry of Testing au mois de février : 30 Days of Security Testing.

1. Compulser la documentation
2. Apprendre les bonnes pratiques
3. Découvrir les outils
4. Aller plus loin

Les challenges

Défi 3 : Use a security tool – Examples: ZAP or BurpSuite & Défi 8 : Utiliser un outil de proxy pour étudier le trafic d’un site web ou d’une application mobile

Comme nous privilégions les solutions open-source, notre choix s’est tourné vers ZAP (Zed Attack Proxy, anciennement WebScarab). ZAP est une application lourde qui peut être enrichie par une gamme d’extensions. BurpSuite nous a semblé prometteur, mais comme les fonctionnalités qui nous intéressaient le plus sont payantes (voir le tableau des formules), nous l’avons laissé de côté.

La prise en main de ZAP est très rapide. Une fois l’installation terminée, l’utilisateur est invité à entrer une URL à attaquer. Après validation, le diagnostic commence.

Attention, il faut avoir une autorisation écrite pour attaquer un site qui n’est pas à soi. Pour tester ZAP, nous avons d’abord lancé une analyse en local sur notre test ISTQB.

Après quelques secondes, une liste d’alertes est générée, qui affiche les failles de sécurité identifiées.

Dans le détail de chaque alerte, il est clairement expliqué en quoi la pratique mise en avant est dangereuse, par exemple, ci-dessous, la corrélation directe entre absence d’en-tête X-Frame-Options et risque de ClickJacking. Dans cet exemple, la traduction française est prise en charge, mais ce n’est pas toujours le cas.

Dans un deuxième temps, nous avons réalisé une attaque sur une de nos applications de test, qui contient un formulaire d’inscription. Et là, ZAP s’en donne à coeur joie : en une minute, une centaine de nouveaux comptes sont créés. Aucune alerte n’apparaît, mais le problème est bien visible.

Défi 6 : Explorer Google gruyere, HackYourself First, Ticket Magpie et The BodgeIt store

Google Gruyere, Hack Yourself First, Ticket Magpie et The BodgeItStore sont de sites à vocation pédagogique que contiennent de nombreuses failles de sécurité. Ce sont des terrains de jeu où l’utilisateur est encouragé à effectuer des tests de sécurité. Retenez bien ces adresses ; le nombre d’applications dont vous avez le droit de tester la sécurité est très réduit, et celles-ci en font partie.

Lançons un scan ZAP sur Hack Yourself First. Comme promis, une flopée de failles de sécurité sont découvertes :

Rendons-nous sur la page où est diagnostiquée la première erreur.

Maintenant, si nous entrons une valeur inattendue pour le paramètre orderby (par exemple « youpi »), l’erreur n’est pas correctement gérée ; nous obtenons une stack d’erreur qui contient des informations fort intéressantes. Ici, en fin de page, le type et la version du framework utilisé pour développer cette application.

Un comportement à la fois risqué d’un point de vue de la sécurité, et désagréable d’un point de vue UX.

Nous avons découvert un autre site proposant des exercice des hacking, Hack this Site!, qui propose des tutoriels de hacking à niveau croissant.

Défi 13 : Intégrer un aspect de sécurité dans une user story

Ce défi en cache un autre : comment intégrer les tests de sécurité à un cycle de développement agile ?

Approche « utilisateur honnête »

Si l’on reprend l’exemple précédent d’un point de vue utilisateur, cette user story pourrait être :

« En tant qu’utilisateur (inscrit ou non) de Supercar Showdown, je veux obtenir une réponse compréhensible quels que soient les caractères que j’ajoute à la suite de l’URL, afin que mon expérience sur le site soit fluide et cohérente.

Critères d’acceptation :

• Lorsque l’utilisateur modifie les paramètres de l’URL en entrant une chaîne de caractères aléatoire (incluant ou non des caractères spéciaux), il est redirigé sur une page d’erreur indiquant « La ressource demandée n’existe pas. »
• Lorsque l’utilisateur effectue une traversée de chemin, si le répertoire parent ne redirige sur aucune page, il doit rediriger vers la page d’erreur précédemment évoquée. »

Vérifions que cette user story est conforme au modèle INVEST :

• Indépendante : (oui)
• Négociable : oui, car la mention « quels que soient les caractères que j’ajoute » peut être précisée selon les besoins du client.
• Valorisable : oui, et l’intérêt est double : une meilleur expérience client et une meilleure protection des informations techniques du produit.
• Estimable : (oui)
• Suffisamment petit : à valider selon la complexité de l’architecture technique du site.
• Testable : oui, des critères d’acceptabilité sont présents.

Certaines affirmations sont entre parenthèses car elles dépendent du reste du projet (autres US, taille de l’équipe, durée des sprints, complexité de l’application…), élément sur lesquels nous n’avons pas assez d’informations.

Approche hacker

Afin d’intégrer pleinement les tests de sécurité aux projets agiles, la fondation OWASP (Open Web Application Security Project, qui est à l’origine du logiciel ZAP) recommande de créer des user stories « diaboliques » (evil user stories), dont le protagoniste n’est autre qu’un hacker. L’enjeu est, à chaque sprint, de s’assurer que ces user stories ne passent pas dans la colonne « terminé ». Nous aurons alors :

« En tant que hacker, je peux accéder aux stacks d’erreur afin de collecter des informations techniques sur l’application. »

Critères d’acceptation :

• Lorsque l’utilisateur modifie les paramètres de l’URL en entrant une chaîne de caractères aléatoire (incluant ou non des caractères spéciaux), il est redirigé sur la stack d’erreur générée automatiquement par le framework.
• Lorsque l’utilisateur effectue une traversée de chemin, si le répertoire parent ne redirige sur aucune page, il doit rediriger vers la stack d’erreur. »

Une autre appellation de ce type d’US : abuser story.

Approche implicite

Une autre approche consiste enfin à intégrer la sécurité dans la définition de « terminé ». Quelques exemples d’implémentation de cette stratégie peuvent être trouvés ici.

Défi 16 : Trouver comment créer une tiger box

Une tiger box est un ordinateur contenant les outils requis pour réaliser un audit de sécurité. Cet ordinateur doit pouvoir mettre à disposition plusieurs systèmes d’exploitation. Cela peut se faire en créant plusieurs options de boot ou en utilisant des outils tels que VirtualBox.

La distribution Linux nommée Kali Linux est une tiger box en soi. Dédiée à la sécurité informatique, elle contient une suite d’outils de test d’intrusion.

Défi 25 : Trouver et utiliser un outil de sécurité mobile

La fondation OWASP propose une application mobile de sécurité gratuite nommée SeraphimDroid. Elle identifie rapidement les failles de sécurité d’un téléphone, ajoute un niveau de sécurité supplémentaire en permettant plusieurs types de verrouillage :

• automatique, par application. A chaque fois qu’il souhaite les utiliser, l’utilisateur déverrouille avec un code d’accès les applications qu’il a choisies.
• automatique, par géolocalisation. L’appareil devient inutilisable s’il sort d’un périmètre défini par l’utilisateur.
• manuel, à distance.

L’application avertit l’utilisateur lorsqu’il reçoit des SMS ou MMS malveillants.

Davantage d’informations dans cette documentation.

Conclusion

• Il existe des sites web spécialement conçus pour qu’on les hacke afin de se former aux tests de sécurité.
• Des outils permettent d’établir un diagnostic rapide des failles de sécurité les plus connues. Les scans sont si rapides qu’ils peuvent être faits en environnement de test ou de préproduction à chaque nouveau déploiement de l’application.
• Il est possible d’inclure des outils de test de sécurité dans une chaîne d’intégration continue. Le test de sécurité agile est en pleine expansion.

Mots clés : test de sécurité, Ministry of Testing, scan de vulnérabilité, test d’intrusion, pentest, ANSSI, ISO 27 000, STRIDE, OWASP

Le principe

Bienvenue dans notre deuxième article consacré au défi 30 Days of Security Testing.

1. Compulser la documentation
2. Découvrir les bonnes pratiques
3. Découvrir les outils
4. Aller plus loin

Les challenges

Défi 4 : S’informer sur les scans de vulnérabilité

Le scan des vulnérabilités est une technique de recherche proactive et automatisée des failles de sécurité d’un système. Une liste de failles est recherchée, puis un reporting est généré pour savoir lesquelles se trouvent effectivement dans le système. Le logiciel ZAP (dont nous parlerons dans un prochain article) est un outil de scan des vulnérabilités.

Même s’ils permettent d’identifier rapidement un certain nombre de problèmes, les scans de vulnérabilité ne sont pas suffisants pour assurer la sécurité d’un système d’information ou d’un applicatif donné. Premièrement, parce que toutes les failles existantes ne peuvent être répertoriées, et a fortiori par un seul outil. Deuxièmement, parce que les scanneurs de vulnérabilités ne permettent pas de simuler une situation d’attaque sophistiquée.

Il est donc nécessaire de mettre en place, en plus des scans de vulnérabilités, des tests d’intrusion mettant en oeuvre une stratégie d’attaque plausible.

Défi 5 : Découvrir un outil de modélisation des menaces (par exemple, le modèle STRIDE)

L’évaluation des menaces est essentiel si l’on souhaite renforcer la sécurité de son SI. Le modèle STRIDE répond à ce besoin. Cet acronyme signifie :

• Spoofing of user identity (usurpation d’identité). Cela peut se faire en cassant un mot de passe.
• Tampering (falsification de données).
• Repudiation. La répudiation est le fait de pouvoir nier avoir pris part à une action sur le système informatique. Il est critique d’assurer la non-répudiation lors des transactions en accumulant des preuves que cette transaction a bien été effectuée.
• Information disclosure (divulgation d’informations).
• Denial of service (déni de service). Le fait de rendre indisponible un service, que ce soit universellement ou pour une cible donnée.
• Elevation of privilege (élévation du privilège). L’utilisateur se voit obtenir des droits qu’il n’est pas censé avoir. Il peut accéder à des informations ou effectuer des actions qui n’étaient pas prévues.

Un même scénario faire intervenir plusieurs de ces pratiques frauduleuse.

Voici un exemple d’application du modèle STRIDE, publié par le département d’informatique et de recherche opérationnelle de l’université de Montréal.

Défi 7 : S’informer sur les tests d’intrusion

Un test d’intrusion, ou pentest, est un test où l’on simule une attaque visant à outrepasser la sécurité d’un système afin d’obtenir, corrompre ou rendre indisponibles des informations. Le but est de révéler, par la pratique, les failles de sécurité spécifiques au système testé.

Un test d’intrusion commence par une analyse des traces laissées par le système que l’on veut tester (ses empreintes, ou footprints). Cela passe par des informations directement trouvables sur le web (informations sur les collaborateurs, politiques de confidentialité), ainsi que des informations techniques telles que son adresse IP (en effectuant un simple ping du site concerné), éventuellement les autres sites qui se trouvent sur la même IP, la date d’expiration du nom de domaine (ce que permet Whois), etc. Des informations techniques peuvent être trouvées via une simple requête dans un moteur de recherche. On parle alors de Google dorks.

Viennent ensuite :

• la phase de scanning, où l’on cherche par exemple quels ports sont ouverts ou quelles machines sont actives,
• l’énumération, où les informations recueillies sont utilisées pour effectivement entrer dans le système,
• l’exploitation, où les actions sont effectuées au sein même du système.

L’un des intérêts d’un test d’intrusion est de comprendre quelles informations il serait stratégique de tenir secrètes, et quelles actions interdire au sein du système, afin d’éviter d’être confronté à des attaques similaires.

Comme vu précédemment, il est intéressant de combiner scans de vulnérabilités et tests d’intrusion.

	Scans de vulnérabilité	Tests d’intrusion
Fréquence de lancement	Haute.   Cela peut être fait à chaque itération.	Relativement basse.   Les investissements en tests d’intrusion dépendent évidemment du niveau de risque associé.
Contenu des reportings	Liste des vulnérabilités, comparatif avec les précédents résultats.	Liste des données en danger.
Coût	Faible   Les outils de scan demandent généralement peu d’efforts de configuration. Leur coût d’exécution est nul.	Elevé   Trouver les failles spécifiques demande davantage de temps, et souvent l’intervention d’experts indépendants.
ROI	Immédiat. Une liste de défauts est rapidement générée, qui permet de planifier les prochaines corrections.	Garanti, proportionnel à l’expertise de l’équipe de test. Si des failles sont détectées, on anticipe d’éventuelles attaques. Dans le cas contraire, on gagne en confiance dans le produit.

Inspiré d’un schéma du groupe TNS. EDIT du 21 février 2019 : le schéma n’est malheureusement plus disponible en ligne. Et si on le sait, c’est grâce à JSoup et Gatling 🙂

Défi 9 : Découvrir les processus et procédures d’audits de sécurité

La plupart du temps, les audits de sécurité sont menés par des entités externes à l’organisation. L’ANSSI, l’agence nationale de la sécurité des systèmes d’information, définit 5 champs d’investigation :

• Audit d’architecture
• Audit de configuration
• Audit de code source
• Tests d’intrusion
• Audit organisationnel et physique

Un référentiel d’exigences définit le cadre méthodologique et réglementaire des audits de sécurité. Il comporte également des notions pratiques, telle qu’une échelle de classification des vulnérabilité.

Défi 11 : Essayer d’évaluer la sécurité d’une application + Défi 14 : Développer un plan de test incluant des tests de sécurité

L’intérêt d’une évaluation de la sécurité (en anglais « security posture assessment ») est de pouvoir prendre une décision en fonction des risques. Cette décision peut être de mettre ou non un applicatif en production.

Pour mener à bien cette activité, nous avons procédé de cette manière :

• Définition du périmètre à tester
• Définition de scénarios à l’aide du modèle STRIDE.
• Lancement d’un scan de vulnérabilités avec le logiciel ZAP
• Tests d’intrusion manuels suivant les scénarios les plus critiques
• Etablissement d’une matrice de risques en tenant compte de la facilité à accéder aux informations critiques. La sévérité des risques est calculée en s’appuyant sur le modèle DREAD (Dommages + Reproductibilité + Exploitabilité + Affectation des utilisateurs + Découvrabilité)

Défi 12 : Se demander à quel moment du cycle de développement les tests de sécurité doivent être réalisés

Dans le cycle de développement logiciel, à quel moment faire intervenir les tests de sécurité ?

Les scans de vulnérabilité sont si rapides qu’ils peuvent être lancés à tout moment. L’intérêt est de pouvoir détecter les failles le plus tôt possible afin de pouvoir y répondre rapidement et adéquatement. Des scans peuvent être directement incorporés dans la chaîne d’intégration continue, par exemple grâce aux plugins Jenkins ZAP (Zed Attack Proxy), VAddy, Walti.

Pour ce qui est des tests d’intrusion, la réponse est moins évidente. En effet, il paraît fructueux de ne pas raisonner en fonction du cycle de développement (approche boîte noire), car une attaque extérieure peut survenir à tout moment. Cela dit, le testeur peut également tirer profit des informations qu’il connaît : la date et l’heure du déploiement en environnement de test, certains mots de passe, ou encore les dates de congés de l’administrateur système. Avec cette approche « boîte grise », il devient capable de trouver d’autres failles de sécurité.

Nous n’avons pas trouvé de ressources répondant à cette question. Si vous avez des pistes, merci de nous laisser un commentaire.

Défi 22 : Trouver une problématique de sécurité logicielle concernant son environnement technique & Défi 24 : Appliquer une suggestion issue de la checklist OWASP Web Application Security

Cette checklist se trouve ici.

En plus d’être d’une aide pratique au moment de se lancer dans des tests de sécurité d’une application, elle montre que la frontière entre tests fonctionnels et tests de sécurité est assez ténue. Les items à tester lors de la validation d’une fonctionnalité d’authentification illustrent bien cette proximité :

• Force du mot de passe choisi par l’utilisateur
• Fonctionnalité de sauvegarde temporaire des informations de connexion (« Remember me »)
• Fonctionnalité de réinitialisation du mot de passe
• Fonctionnalité de changement du mot de passe
• CAPTCHA
• Authentifications à plusieurs facteurs
• Déconnexion
• Présence d’identifiants par défaut
• Notifications (de succès ou d’échec)
• Authentification inter-applicative utilisant une authentification unique (SSO)
• Force des questions servant à la récupération des mots de passe

Défi 29 : Chercher des standards de sécurité spécifiques à un domaine

Une famille de normes est consacrée à la sécurité de l’information : ce sont les normes ISO 27000. Cette page fournit un schéma qui permet de comprendre leurs liens de parenté.

Un audit de sécurité peut être effectué dans l’optique d’obtenir la certification ISO 27001, qui établit des spécifications de sécurité de l’information. Dans ce cas, le processus dure trois ans. Lors de la première année, un audit complet est effectué et les non-conformités sont résolues. Un suivi est effectué lors des deux années suivantes.

Cette norme est destinée à accompagner la mise en place d’un système de management de la sécurité de l’information (SMSI). Respectant explicitement le principe de la roue de Deming (PDCA : Plan, Do, Check, Act), elle illustre parfaitement la maxime du cryptologue Bruce Schneier : « Security is not a product; it’s a process ». Elle est téléchargeable gratuitement à cette adresse.

La norme ISO 27002, qui se réfère étroitement à la 27001, développe plus en détail les bonnes pratiques, ne représente pas une condition pour obtenir la certification.

Conclusion

• Les objets et les techniques des test de sécurité sont multiples. Mettre en oeuvre les tests adéquat requiert une étude approfondie du contexte.
• Comme pour les tests fonctionnels, il existe une complémentarité entre les tests manuels et automatisés. Il ne s’agit pas de choisir entre l’une et l’autre de ces approches.
• La sécurité de l’information, même si elle n’est jamais totalement garantie, peut être favorisée au sein d’un organisation par l’application de standards nationaux et internationaux.

Rendez-vous sur notre article suivant, qui porte sur les défis liés aux outils de test de sécurité !

Le principe

Ministry of Testing est une mine d’or qui permet de se tenir au courant de ce qui se passe dans le monde du test. Au début du mois de février, un défi a été lancé dans le Dojo, l’espace dédié à sa communauté : 30 Days of Security Testing. Le principe : pendant un mois, se former aux tests de sécurité en réalisant 31 défis.

Pourquoi participer ?

Les tests de sécurité représentent une discipline à part entière, voire plusieurs disciplines. Le but de ce défi est de prendre la mesure des risques, des types de solutions et des méthodologies existantes, afin d’enrichir sa façon de tester.

Notre feuille de route

Nous avons réparti les 31 défis du Dojo en 4 catégories, dont chacune fera l’objet d’un article.

1. Compulser la documentation
2. Découvrir les bonnes pratiques
3. Découvrir les outils
4. Aller plus loin

Comme la répartition est thématique, les numéros des défis ne se suivent pas forcément.

Avant de commencer

Attention, les tests de sécurité font appel à des techniques qui, selon la façon dont elles sont employées, peuvent être illégales. Il est de la responsabilité du testeur d’obtenir les autorisations nécessaires avant de pratiquer des tests de sécurité sur un système. Soyez très précautionneux avant de vous servir des tutoriels et des outils à votre disposition. Si vous avez un doute, préférez ne rien faire plutôt que de risquer des poursuites, ou mettre en danger le fruit du travail d’autres personnes.

Les challenges

Défi 1 : Lire un blog sur la sécurité informatique

Nous avons apprécié le blog de Veracode, qui contient de bons articles de fond sur l’implémentation d’une politique de sécurité au sein d’une entreprise. Celui-ci évoque les réactions parfois conflictuelles des équipes de développement lorsqu’elles sont confrontées à leurs responsabilités en termes de sécurité informatique.

Défi 2 : Lire un livre sur les tests de sécurité

La sécurité informatique n’est pas seulement une affaire d’outils, mais également de prudence humaine. Afin d’explorer ce deuxième axe, nous avons choisi de lire L’Art de la supercherie de Kevin Mitnick (2002), un livre qui fournit de nombreuses pistes pour contrer les attaques basées sur l’ingénierie sociale.

Dans le domaine de la sécurité de l’information, l’ingénierie sociale est une pratique qui consiste à extorquer des informations en abusant de la crédulité des personnes qui y ont accès. Selon l’auteur, le facteur humain représente le pire danger dans le domaine de la sécurité informatique.

Une information jugée anodine, comme un terme de jargon (qui n’est pas traitée en soi comme une information confidentielle), peut être un outil redoutable pour une personne souhaitant obtenir, en abusant de la confiance des collaborateurs, des informations plus sensibles.

L’auteur développe la notion de compromis entre sécurité et productivité. Une attitude trop laxiste ou insouciante est évidemment dangereuse, mais une position trop défensive peu donner une mauvaise image de l’entreprise, aussi bien que des processus trop sécurisés peuvent freiner la performance d’une entreprise.

Ce livre est donc une excellente base de réflexion sur l’ingénierie sociale. Une lecture complémentaire : cette liste des 25 principaux biais cognitifs. La plupart des biais énumérés peuvent être exploités afin de mettre en danger la sécurité informatique d’une entreprise. La croyance en un monde juste est un biais très commun, souvent évoqué par Kevin Mitnick, et qui représente souvent un obstacle à la compréhension des politiques de sécurité informatique.

Défi 18 : S’informer sur les en-têtes de sécurité

Les en-tête HTTP (ou headers en anglais) contiennent des informations échangées par le navigateur et le serveur. Ils impactent la façon dont l’un et l’autre devront se comporter. Quand un navigateur envoie au serveur l’en-tête user-agent, il lui donne des informations sur sa version, son système d’exploitation ou la langue utilisée. En retour, le serveur peut renvoyer une page web adaptée au profil du navigateur.

Pour savoir quels en-têtes renvoie un site web en particulier, rendez-vous sur Web Sniffer.

Certains en-têtes jouent un rôle critique en sécurité informatique, comme X-XSS-Protection, qui protège contre une partie des risques de cross-site-scripting. Un site web existe, qui permet d’évaluer la sécurité d’un site web par la configuration de ses en-têtes HTTP : Security Headers.

Pour en savoir plus, et en particulier sur la manière de modifier les en-têtes HTTP, nous vous conseillons cet article.

Défi 19 : Comprendre ce que sont les « script kiddies » et les « packet monkeys »

Les Script Kiddies sont « les hackers débutants qui ne s’embarrassent pas de connaissances techniques et se contentent de télécharger les outils des hackers pour s’introduire dans des systèmes informatiques » (Kevin Mitnick, L’Art de la supercherie).

Les Packet Monkeys sont des Script Kiddies qui se spécialisent dans l’envoi massif de paquets en vue de provoquer des dénis de service.

Défi 21 : Trouver une problématique de vulnérabilité réseau concernant son environnement technique

Une problématique réseau nous concerne en particulier, à savoir la sécurité des réseaux Wifi.

Sécuriser son réseau Wifi, quels enjeux ?

• Sécurisation des données : un réseau mal protégé peut permettre l’interception de données ou l’accès aux données des ordinateurs du réseau.
• Disponibilité du réseau : des scripts mal intentionnés peuvent brouiller les transmissions ou provoquer des dénis de service, rendant la Wifi inutilisable.
• Responsabilité de l’utilisation des données : en cas d’utilisation frauduleuse d’Internet (ex : téléchargements illicites), le propriétaire du réseau utilisé est très souvent mis en cause. La loi Hadopi notamment pointe du doigt les propriétaires faisant preuve de « négligence caractérisée », même si c’est une autre personne qui exploite illégitimement leur réseau.
• Protection des ressources : si un inconnu se retrouve capable d’utiliser le réseau Wifi pour accéder à Internet, les performances seront affectées en fonction de son utilisation. Cela peut, en corollaire, faire augmenter la facture du FAI.

Des applications mobiles telles que Fing permettent d’obtenir la liste des autres appareils connectés sur le réseau WIFI, ainsi que leur nom, leur IP locale, leur marque, leur adresse MAC (Media Access Control), et ainsi initier une phase de scanning. Ces informations sont même directement exploitables : l’adresse MAC peut en effet être utilisée à des fins d’usurpation d’identité, ce qui peut se révéler utile en cas de filtrage d’accès par adresse MAC. Par ailleurs, ces informations peuvent également être utiles dans une stratégie reposant sur l’ingénierie sociale.

Les enjeux que nous venons d’évoquer reflètent des menaces pouvant être extrêmement critiques. Or, au sein d’une société, il est monnaie courante de partager son accès Wifi auprès de ses clients, prospects, ou toute personne participant à des ateliers animés en interne. Il est intéressant d’évaluer les risques qu’une telle pratique présente. La problématique soulevée par Kevin Mitnick dans L’Art de la supercherie (sécurité versus productivité) est tout à fait éclairante ici.

Bonus

Une vidéo de Bruce Schneier, qui donne une vision intéressante et pragmatique de ce qu’est la sécurité. La sécurité (informatique ou non) est envisagée comme un processus toujours en action, une suite d’échanges et de compromis dont on juge à chaque instant s’ils sont avantageux.

Conclusion

Ce que nous retenons de cette première approche des tests de sécurité :

• Il s’agit d’une discipline à part entière, mais dont les frontières se mêlent avec d’autres problématiques qui nous sont proches : tests système, tests d’intégration, tests de maintenabilité. Afin d’assurer une approche globale de la qualité, un testeur gagne à maîtriser les fondamentaux des tests de sécurité.
• La sécurité informatique est l’affaire de tous les employés de l’entreprise. Il existe une tendance de fond qui consiste à responsabiliser les équipes techniques quant aux risques d’intrusion.
• De même qu’il est impossible de prouver l’absence d’anomalies dans une application (c’est le premier principe du test logiciel), il est impossible de prouver l’absence de faille de sécurité. Assurer la meilleure sécurité possible requiert les mêmes qualités de pessimisme et de pragmatisme que dans les autres branches du test.

A bientôt pour la prochaine partie de cette série !