Exemple de triage

Cet exemple décrit un flux de travaux de triage AppScan® Source utilisé par un analyste de la sécurité. Le flux de travail de triage peut varier en fonction des besoins de votre activité.

M. Jones, l'analyste de la sécurité de l'entreprise, désire effectuer un triage des résultats de son examen. Il désire regrouper des constatations similaires et leur affecter des priorités avant de les soumettre au développeur approprié pour leur résolution.

M. Jones examine tout d'abord le code source de son application et ouvre ensuite l'évaluation dans la perspective Triage. L'examen génère environ 2 000 constatations qu'il peut examiner dans la vue Constatations. Il désire toutefois consulter un aperçu des résultats et ouvre la vue Matrice des vulnérabilités, laquelle les décompose par gravité et par type de constatation (sécurité ou couverture d'examen). Les constatations de couverture d'examen et les constatations de sécurité suspectées nécessitent un examen supplémentaire pour déterminer le risque.

Dans la matrice des vulnérabilités, M. Jones identifie huit constatations de sécurité définitives à gravité élevée. Il clique sur la zone de la matrice identifiant ces huit constatations définitives, ce qui a pour effet de créer automatiquement un filtre et la vue Constatations est alors actualisée pour ne plus afficher que ces huit problèmes critiques. M. Jones décide de traiter ces problèmes en tant que bogues. Il sélectionne les huit et les soumet à son système de suivi des défauts. Il réinitialise ensuite son filtre dans la matrice des vulnérabilités.

M. Jones s'intéresse ensuite à la vue Récapitulatif de l'évaluation. Il constate que les 2 000 constatations couvrent plus d'une demi-douzaine de types de vulnérabilités. Il décide de se concentrer sur les problèmes de validation et crée un nouveau filtre depuis la vue Récapitulatif de l'évaluation. Il clique dans le graphique sur Validation.EncodingRequired et Validation.Required ce qui réduit le nombre d'éléments dans la vue Constatations à environ 500 résultats.

Le triage de cinq cent constatations est encore difficile. M. Jones décide donc de les filtrer plus avant. Depuis la vue Editeur de filtre, il adjoint au filtre créé dans le Récapitulatif de l'évaluation une exigence de gravité élevée. Le Tableau des constatations ne comporte plus à présent que 150 entrées.

Lorsqu'il les trie par nom de fichier, il constate que certaines constatations utilisent le code d'une bibliothèque d'un éditeur tiers. M. Jones sait que l'utilisation de cette bibliothèque est isolée des autres et qu'il ne compte pas intervenir sur ses problèmes de sécurité. Il exclut ces constatations associées ce qui entraîne la mise à jour immédiate de la vue Constatations et des métriques. Les examens ultérieurs détecteront ces constatations mais celles-ci seront isolées et ne contribueront pas aux métriques.

M. Jones identifie plusieurs constatations de sécurité suspectées à gravité élevée de type Validation.Required. Il est conscient que ces données sont utilisées sans aucune validation. Il décide de les promouvoir du type Suspectée au type Définitive. En apportant cette modification, il décide d'ajouter des notes pour expliquer ses modifications, puis s'expédie à lui-même ces constatations pour se rappeler d'attribuer une priorité appropriée à leur résolution ou de les analyser dans la vue Constatations modifiées.

M. Jones les trie à nouveau par nom de fichier et s'aperçoit que certaines proviennent du serveur dorsal et d'autres de l'interface utilisateur. Il sélectionne alors toutes les constatations relatives au serveur dorsal et crée un nouveau groupement qu'il intitule Backend Server - Validation Required. Il sélectionne les constatations restantes et les place dans un groupement intitulé UI - Validation Required. Le triage se poursuit en se concentrant sur les types Validation.EncodingRequired avec gravité élevée.

En fin de journée, M. Jones a créé une douzaine de groupements. Au cours de la journée, il a utilisé le graphique, les filtres et la matrice de vulnérabilités pour élaguer les constatations et les regrouper dans des vues distinctes gérables. Certaines de ces constatations ont été parfois amalgamées dans des groupements. D'autres, sans importance, ont été exclues. A l'occasion, il crée de nouveaux groupements pour des constatations spécifiques ; à d'autres, il ajoute des constatations à un groupement existant.

M. Jones examine ensuite sa douzaine de groupements. Il conclut qu'il doit soumettre les groupements Backend Server - Validation Required et UI - Validation Required au système de suivi des incidents pour aviser les développeurs de ces préoccupations.

M. Jones accède à la vue Groupements et ouvre celui intitulé Backend Server - Validation Required. Une nouvelle vue intitulée Serveur dorsal - Validation requise s'ouvre en affichant la liste des constatations qu'il a placées dans ce groupement. Il soumet ensuite ce groupement à un système de suivi des défauts. Plus tard dans la nuit, lorsque le développeur se connecte à Rational® ClearQuest® et prend connaissance des bogues qui lui ont été affectés, il peut ouvrir la constatation dans AppScan® Source for Development.

M. Jones examine ensuite les autres groupements. Il en soumet certains au système de suivi des défauts et en envoie d'autres à ses collègues par courrier électronique. Cependant, certains groupements contiennent des constatations qui, après examen supplémentaire, ne lui semblent pas importants. Il les déplace dans deux nouveaux groupements intitulés By Design et Irrelevant. M. Jones a conclu que ces constatations sont acceptables et n'a pas l'intention de changer leur code. Outre les constatations des groupements By Design et Irrelevant, M. Jones réalise que toutes celles concernant la vulnérabilité Cryptography.PoorEntropy ne sont pas non plus importantes. Il sait que l'entropie de ces appels de cryptographie peut être faible et bien qu'un ordinateur rapide puisse déchiffrer leur clé en moins d'une semaine, ceci n'a guère d'importance pour une application dans laquelle les données sont périmées quelques heures après leur chiffrement. Il désire donc également les supprimer.

Il ajoute alors les groupements By Design et Irrelevant vers la liste Groupements exclus dans la vue Propriétés. Il ouvre également l'éditeur de filtre et crée un autre filtre avec le type de vulnérabilité Cryptography.PoorEntropy, sauvegarde le filtre sous le nom Crypto et affecte au comportement du filtre Crypto la valeur Inversé (dans la boîte de dialogue Sélection de filtre, il choisit l'option Inverser le filtre). Il lance alors un examen avant de rentrer chez lui. Les métriques ne reflètent pas ces exclusions avant l'examen suivant.