Tout au long du cours, nous avons appris un certain nombre de méthodes pour découvrir des
bogues et des vulnérabilités dans différents types de logiciels et d'infrastructures, généralement à la fin du test, vous devrez informer le client de toutes
les vulnérabilités que vous avez trouvées ou de toutes les résultats.
Cela se fait à l'aide d'un rapport de test.
Donc, fondamentalement, ce que nous entendons par rapport de test, c'est juste un document qui inclut tout ce que
vous avez trouvé lors de votre engagement afin que le client ou l'administrateur puisse aller de l'avant et corriger toutes les vulnérabilités et les
faiblesses que vous avez trouvées.
Ces rapports sont également lus par les dirigeants la plupart du temps.
Par conséquent, vous devrez en tenir compte.
Donc, un bon rapport devrait être assez facile.
Mais il est également facile à comprendre maintenant si vous travaillez en tant que testeur, alors l'entreprise pour laquelle vous
travaillez aura probablement son propre modèle et ses propres normes que vous devrez suivre lors de la rédaction d'un
rapport.
Et dans de nombreux cas, vous ne le ferez même pas.
Vous transmettrez simplement vos conclusions à un autre membre de votre propre équipe et ils rempliront correctement
les blancs dans le rapport.
Par conséquent, vous n'aurez probablement pas besoin d'en écrire un à partir de zéro.
Et dans de nombreux cas, vous n'écrivez même pas le rapport réel que le client voit.
Cela étant dit, je veux quand même vous montrer comment cela se fait, juste pour vous donner une idée de ce à
quoi ressemble un rapport de test.
Maintenant, tout d'abord, avant de vous montrer l'échantillon que j'ai, je vais inclure
ce référentiel, qui contient essentiellement un grand nombre de rapports Pantazis.
Vous pouvez donc les parcourir pour vous inspirer et simplement voir les différents styles que les différentes entreprises suivent
lors de la rédaction d'un rapport de test.
Vous pouvez donc cliquer sur l'un d'entre eux et vous trouverez le rapport et vous pouvez le parcourir
pour savoir comment cette entreprise spécifique, vous rédigez ses rapports et peut-être trouvez-vous quelque chose que vous aimez et que
vous commencerez à inclure dans votre propre rapport. .
Je vais donc inclure cela dans les ressources de la conférence afin que vous puissiez y revenir pour vous inspirer.
Mais ce que je veux vraiment faire, c'est vous présenter un échantillon de rapports que nous utilisons ici en matière de sécurité.
Juste pour vous donner une idée des sections principales de la plupart des rapports.
Je vais également inclure cela dans les ressources.
Alors n'hésitez pas à le modifier et à l'utiliser ou à en reprendre quelques éléments si vous le souhaitez.
Vous remarquerez donc à partir du référentiel ici, que chaque entreprise a son propre style de rédaction de rapports,
mais en général, il y a toujours quelques sections principales que vous trouverez dans chaque rapport.
Donc, en commençant par la première page ici, nous avons la page de couverture.
Donc, encore une fois, vous pouvez vendre cela comme vous le souhaitez.
Vous avez généralement le logo de l'entreprise, vous avez le titre, puis vous avez la date du rapport et
la version.
C'est très important.
Et puis nous avons l'entreprise, les informations de notre entreprise.
Ce rapport est donc rédigé par nous.
Ce sont les informations de notre entreprise.
Et puis vous avez dans le champ de force, vous avez l'entreprise pour laquelle vous écrivez ce rapport.
Vous aurez donc le nom de l'entreprise, vous aurez un identifiant spécifique pour cette entreprise.
C'est l'idée que vous avez identifié cette entreprise dans vos propres dossiers.
Encore une fois, ce n'est probablement pas quelque chose que vous ferez vous-même.
Cette idée vous sera donnée par votre propre entreprise.
Et puis nous avons les coordonnées des deux sociétés.
Vous pouvez donc voir que dans cette entreprise, nous avons celui-ci, puis le testeur deux avec leurs adresses e-mail.
Cela pourrait évidemment être une liste plus longue avec toute l'équipe qui fait le test et similaire à l'entreprise
pour laquelle vous faites le test.
Encore une fois, vous avez leurs noms, leur position dans l'entreprise et leurs coordonnées.
Maintenant, encore une fois, gardez à l'esprit que vous n'avez pas toujours à styliser la première page comme ça, mais
plus ou moins généralement dans la première page, vous aurez le titre, la date, la version et les coordonnées.
C'est comme ça qu'on le fait.
Mais encore une fois, vous pouvez le faire comme vous le souhaitez et vous pouvez vous inspirer de la ressource que je
vais inclure ici.
Ensuite, nous avons généralement à nouveau la table des matières, comme vous pouvez le voir, des choses simples auraient généralement
dans n'importe quel type de document.
Cela vous aidera à naviguer dans l'ensemble de ce document.
Et comme je l'ai dit ici, nous pouvons voir les sections principales de tout rapport de protestation.
Il est donc très important d'avoir un résumé.
Ceci est un résumé de l'ensemble de l'engagement qui est conçu pour les personnes moins techniques.
C'est donc censé leur donner une idée de vos découvertes sans trop plonger dans les détails techniques.
Ensuite, nous avons un résumé de l'engagement où nous détaillons la portée.
Voici donc ce que vous avez testé, les parties de leur système que vous avez testées, les cotes de risque que
vous avez utilisées et un aperçu de tout ce que vous avez trouvé.
Donc, encore une fois, jusqu'à présent, nous ne plongeons pas profondément ou simplement ce n'est qu'un résumé de l'ensemble de l'engagement.
Vous aurez une meilleure idée de tout cela en parcourant le rapport.
Et puis dans la section des détails techniques, c'est là que vous plongez vraiment dans tout ce que vous avez
trouvé.
Nous avons donc essentiellement une section pour chaque résultat.
Comme vous pouvez le voir, ceci n'est qu'un échantillon.
Je n'ai donc fait que trois constatations.
Nous avons l'injection initiale, une contrefaçon de demande intersite.
Oui.
SRF et une divulgation d'informations.
Donc, comme vous pouvez le voir dans la première section, nous n'avions essentiellement qu'un résumé de
tout ce que nous avons trouvé, alors que dans les détails techniques, nous décomposions essentiellement chaque découverte.
Et nous allons parler de la façon dont nous l'avons trouvé en détail, comment le reproduire.
Vous allez inclure des captures d'écran, si vous le pouvez, afin que l'équipe technique puisse comprendre exactement la
gravité de cette vulnérabilité et comment la corriger.
Vous remarquerez que d'autres sociétés incluront une annexe à la fin, elles incluront des recommandations où
elles vous diront exactement comment corriger les vulnérabilités.
Comme je l'ai dit, cela dépend vraiment de l'entreprise.
Chaque entreprise a son propre style et chaque entreprise a son propre format.
Donc, ce que je vous montre ici n'est qu'un exemple de la façon dont nous procédons.
Vous pouvez vous inspirer des ressources et, dans de nombreux cas, vous devrez simplement suivre le modèle de votre
entreprise car elle ne veut pas que vous le fassiez à votre manière.
Passons donc à la page suivante et vous verrez dans cette page nous avons les informations légales.
Et c'est pourquoi j'ai dit que vous ne feriez probablement pas cela vous-même.
Vous n'aurez jamais besoin de le faire vous-même car vous aurez des parties du rapport comme celle-ci.
Vous n'aurez jamais à les modifier et ils seront en fait rédigés par l'équipe juridique de votre entreprise.
Ainsi, ils prendront en compte tout ce qui pourrait devenir incontrôlable pour s'assurer que vous ne serez pas poursuivi.
Si quelque chose ne va pas, il contiendra des éléments tels que des clauses de non-responsabilité, le PIB, notre vie privée, des éléments juridiques et tous
ces éléments que nous ne connaissons pas très bien.
Les testeurs et les juristes écrivent généralement, puis nous avons le journal des modifications du document.
Donc, chaque fois qu'un changement est apporté au document, vous pouvez voir que nous avons la date, nous avons la version
et nous avons un commentaire.
Pourquoi avons-nous fait ce changement ou qu'est-ce qui est si important dans ce changement ?
C'était donc le rapport initial lorsque nous l'avons fait le 1er janvier et puis le 10 janvier, nous avons fait une deuxième
version où nous en avons terminé avec la deuxième étape.
Encore une fois, ce ne sont que des échantillons.
Mais juste pour vous donner une idée, il est très, très important de tenir un journal des modifications de
tous les changements que ce document subit.
Toutes les entreprises ne le font pas.
Mais encore une fois, c'est juste notre propre choix de l'ajouter dans notre rapport.
Je n'arrête pas de dire cela juste pour vous donner une idée qu'il n'y a pas de règles établies pour faire ce genre de documents.
Vous pouvez ajouter ou supprimer tout ce que vous voulez, mais les parties principales seraient la partie juridique, le
résumé et la partie technique.
Ce seront les principales parties du rapport.
Alors maintenant, nous avons le résumé et vous pouvez le lire.
Ce n'est pas censé être long.
Donc, à mon avis, cela doit être une page maximum de deux pages si vous le devez vraiment.
Et cela dit simplement que nous avons été chargés de tester un système.
Il vous expliquera comment ce document est organisé, là où la première section est moins détaillée, histoire de vous
donner une idée du risque.
Et le second est détaillé pour que les techniciens comprennent ces risques et les corrigent, puis ils ont reçu
la cote de risque.
Nous supposons donc qu'il s'agit d'un risque élevé en fonction des vulnérabilités que nous avons trouvées.
Il détaillera la méthodologie que nous avons suivie.
Et puis nous avons quelques graphiques ici.
N'oubliez pas que cette partie est en train d'être lue par les dirigeants.
Ce sont des gens qui ne sont pas très techniques la plupart du temps, et ils n'ont pas non plus beaucoup de temps.
Nous incluons donc des graphiques ici pour leur montrer le nombre de vulnérabilités que nous avons trouvées.
Nous pouvons donc voir que nous avons cinq vulnérabilités qui sont élevées.
Nous en avons 10 qui sont moyennes et huit qui sont faibles.
Cela leur donnera donc une très bonne compréhension des menaces auxquelles ils sont confrontés.
Et puis nous allons revenir dans le résumé.
Ceci sera toujours lu par les personnes moins techniques.
Donc, tout d'abord, nous détaillons la portée pour nous assurer que nous leur disons ce que nous avons testé, même
s'ils nous ont déjà dit quoi tester, juste pour qu'au cas où à l'avenir, si quelque chose était découvert en
dehors de notre portée et ils nous reviennent, on peut dire, eh bien, c'était en dehors du cadre.
Nous n'avons pas testé cela l'année prochaine, y compris la cote de risque.
Vous l'aurez donc dans chaque document.
Vous voulez que je le modifie.
En gros, nous disons simplement comment nous classerions une certaine vulnérabilité comme faible, moyenne, élevée ou
critique.
Et nous disons, à notre avis, comment vous devez gérer les vulnérabilités faibles, moyennes, élevées et critiques que vous pouvez voir pour les
critiques que nous disons que vous devez corriger immédiatement, alors que pour la loi, vous devez corriger dans
le prochain cycle de mise à jour.
Encore une fois, ce n'est que notre propre opinion.
Ensuite, nous avons les conclusions de l'examen.
Nous sommes donc toujours dans la première section.
C'est encore pour les cadres.
Nous n'avons pas besoin de plonger trop profondément.
On nous donne donc juste l'idée de vulnérabilité.
Et vous pouvez voir pour la première vulnérabilité, c'est critique.
C'est une injection Ezekial.
Et dans de nombreux cas, dans de nombreux rapports, ils l'arrêteront en disant que c'est juste une injection d'ESKIL.
Nous aimons montrer l'impact dans cette section car, comme je l'ai dit, ces gars-là ne sont pas techniques.
Donc, s'il s'agit d'une injection, ils pourraient ne pas savoir ce qu'est une injection ESKIL.
Ce qui les préoccupe, c'est l'impact de cette vulnérabilité.
Encore une fois, ils n'ont pas beaucoup de temps, vous devez donc aller droit au but.
Donc, ce que nous faisons, c'est que nous disons qu'il s'agit d'une injection naturelle qui pourrait conduire à un accès autorisé à la base
de données.
Alors maintenant, ils savent qu'avec cette vulnérabilité, un pirate peut accéder à leur base de données.
C'est probablement assez mauvais.
Une autre vulnérabilité que nous avons trouvée est moyenne et excessive.
SRF encore une fois, de nombreux rapports s'arrêteront là, n'explique vraiment rien aux personnes non techniques.
Nous disons donc que les clients peuvent être obligés de soumettre certaines demandes non critiques.
C'est pourquoi c'est une demande médiatique, pas non critique.
Mais ils peuvent être obligés de soumettre des choses.
Et puis nous avons une vulnérabilité où la version HP est divulguée.
Ce n'est donc pas vraiment très critique car ce n'est pas une vulnérabilité réelle qui peut être
exploitée pour accéder ou exposer les données des utilisateurs.
Mais ces informations pourraient être utiles aux pirates pour enchaîner avec d'autres attaques ou découvrir des
vulnérabilités pour cette version spécifique.
Et c'est pourquoi c'est un faible.
C'est pourquoi il n'a pas besoin d'être pris en charge de manière très urgente, comme les critiques, comme nous l'avons
mentionné ci-dessus et ici.
Et n'hésitez pas à lire le texte ici, vous verrez qu'il s'agit essentiellement de se vider le dos et
de s'assurer qu'ils comprennent tout ce qui est dans le rapport.
Et ce serait la fin de l'été.
Et maintenant, nous sommes dans les détails techniques.
Donc, dans cette section, nous avons essentiellement, comme je l'ai dit, une sous-section pour chaque conclusion que nous
avons.
Et nous plongeons très profondément dans les détails de cette découverte.
Vous pouvez donc voir qu'il s'agit de l'injection réelle que nous avons mentionnée plus tôt dans le résumé.
Mais cette fois, nous leur donnons en fait l'URL qui est vulnérable.
Nous leur donnons le paramètre vulnérable.
Nous leur donnons des références pour comprendre ce qu'est l'injection d'Eskil.
Au cas où ils ne le comprendraient pas, nous leur donnons la demande exacte et la réponse exacte que nous
avons obtenue, ce qui nous a permis de déterminer que cette page particulière est vulnérable à une injection.
Ensuite, nous leur donnons l'impact ici en détail, pas seulement en disant qu'ils peuvent accéder à la base de données.
Nous disons donc qu'ils peuvent accéder à la base de données.
Ils peuvent récupérer les données auxquelles nous avons accès dans la table de l'utilisateur.
Vous allez donc plonger dans les détails et vous devriez même inclure des captures d'écran ici.
Si vous pensez qu'ils seront utiles dans la section d'atténuation.
Nous leur donnons juste une recommandation rapide.
Comme je l'ai dit, certaines entreprises donnent des recommandations détaillées.
Cela dépend aussi vraiment de l'engagement.
Donc, dans cet exemple, nous disons simplement utiliser des instructions de préparation avec des requêtes paramétrées et nous leur
donnons une référence pour apprendre comment faire cela ou comprendre comment cela fonctionne.
Et c'est à peu près tout.
Vous allez donc répéter cela pour chaque vulnérabilité que vous avez trouvée ?
Je laisse le reste vide car ce n'est qu'un échantillon, mais vous voyez l'idée.
Vous allez donc avoir une sous-section pour chaque résultat que vous avez tout expliqué en détail afin qu'ils comprennent la
vulnérabilité et qu'ils puissent ensuite aller de l'avant et la corriger.
À la fin, de nombreuses entreprises auraient une annexe et elles pourraient avoir une plus grande section de recommandations,
comme je l'ai dit, c'est notre style de rédaction de rapports que chaque entreprise a son propre style, si vous voulez.
Cela peut prendre un certain temps à parcourir les exemples de rapports que nous avons dans ce référentiel.
Évidemment, j'inclurai les deux liens pour mon échantillon et pour les autres échantillons et les ressources afin que vous
puissiez les parcourir vous-même et avoir une idée de ce à quoi ressemblent les rapports Pennhurst.
Mais comme je l'ai dit, dans de nombreux cas, vous remplirez simplement un échantillon similaire à celui que nous avons ici.
Ainsi, on ne vous demandera jamais d'en créer un à partir de zéro.