Comment rédiger un bon rapport d'audit de sécurité ?
Même le meilleur audit de sécurité d'un site web ou d'une application sera de peu d'utilité si nous ne documentons pas les menaces détectées, les étapes pour les reproduire, les menaces potentielles résultant de leur utilisation et les recommandations pour corriger le bug. Nous vous montrerons comment préparer un rapport détaillé étape par étape.
Que doit contenir un bon rapport d'audit de sécurité ?
Les aspects visuel et substantiel sont tous deux importants. Le rapport doit être esthétique, mais sa partie visuelle ne doit pas dominer ni interférer avec la réception de son contenu. Après tout, c'est le contenu du rapport qui est d'une importance capitale. Dans cet article, nous nous concentrerons sur la partie substantielle. À l'aide d'exemples spécifiques, nous présenterons les composants individuels d'un document résumant un audit de sécurité, à savoir :
- sujet du travail,
- résumé des activités effectuées et de leurs résultats,
- description détaillée des menaces détectées.
Première section – une page de titre avec le sujet de l'audit
Dans cette partie, nous devons inclure des informations sur le contenu du document et indiquer qu'il s'agit d'un rapport d'audit de sécurité. De plus, nous devons préciser le sujet du travail, à savoir les éléments pour lesquels les tests de sécurité ont été effectués. La date à laquelle le travail a été réalisé, le lieu et les personnes responsables de l'audit devraient également être mentionnés. La page de titre ne doit contenir que le sujet clé et général du travail.
Si l'application Foo, son API, le code source et l'infrastructure sur laquelle elle fonctionne ont été soumis à des tests, ces éléments doivent figurer sur la première page du rapport. Par contre, si l'ensemble de l'application a été audité, il ne devrait pas être découpé en parties individuelles lors de la présentation du sujet de l'audit, mais décrit dans son ensemble. Le moment de diviser l'audit en parties plus petites et plus détaillées viendra plus tard.
Rapport de tests de sécurité – un exemple
Sujet du travail :
- Tests de pénétration de l'application Foo
- Tests de sécurité de l'API de l'application Foo
- Analyse du code source de l'application
- Tests de pénétration de l'infrastructure de l'application
Date de réalisation du travail :
01/10/2021 - 10/10/2021
Lieu de réalisation du travail :
Wrocław
Auditeurs:
Jan Kowalski
Deuxième section – le résumé du contenu du rapport
Les pages suivantes devraient contenir le résumé du travail. Elles peuvent être utilisées pour décrire le sujet du travail de manière plus détaillée que sur la page de titre. Le résumé est également l'endroit pour partager les résultats collectifs de l'audit de sécurité réalisé et informer sur les vulnérabilités les plus critiques trouvées lors de l'audit. Les vulnérabilités critiques devraient être brièvement décrites. Toutes les vulnérabilités seront décrites de manière plus détaillée plus tard dans le rapport.
Dans le résumé, les lecteurs peuvent aussi se familiariser avec la classification des vulnérabilités adoptée. Par conséquent, nous devrions lister tous les niveaux et ajouter une description détaillée à chacun d'eux.
Vous trouverez ci-dessous un exemple de description des niveaux de classification des vulnérabilités.
Information
Le niveau Information n'est pas considéré comme une vulnérabilité menaçant la sécurité. C'est un message qui indique de bonnes pratiques qui, si elles sont mises en œuvre, augmenteront le niveau de sécurité global de votre application. À ce niveau, nous verrons aussi des recommandations architecturales, dont la mise en œuvre augmentera la sécurité de l'application.
Faible
La vulnérabilité est insignifiante, son utilisation a un impact négligeable sur la sécurité de l'application, ou son exploitation nécessite de remplir des conditions difficiles à atteindre.
Moyen
La vulnérabilité est modérément significative, ce qui signifie que son exploitation peut nécessiter de remplir certaines conditions qui ne sont pas extrêmement difficiles à atteindre. Elle peut permettre d'accéder à une quantité limitée de données ou à des données classées comme insignifiantes.
Élevé
Une vulnérabilité significative dont l'exploitation permet d'accéder à des données sensibles de l'application, mais son utilisation nécessite de remplir certaines conditions, comme par exemple, avoir un compte avec certaines autorisations. Nous définissons également comme élevées les vulnérabilités qui peuvent être exploitées de manière simple, mais dont les effets ne sont pas critiques.
Critique
Exploiter une vulnérabilité critique permet de prendre le contrôle total du serveur ou d'accéder à des informations importantes et confidentielles. Généralement, elle est facile à exploiter et ne nécessite pas que certaines conditions soient remplies. Les vulnérabilités critiques nécessitent une action immédiate.
Troisième section – les vulnérabilités
Chaque vulnérabilité doit contenir un bref titre décrivant la menace. Le titre doit également inclure le niveau de criticité de la vulnérabilité. Ensuite, nous créons une description dans laquelle nous présentons en détail la menace détectée. S'il y a certaines conditions à remplir pour exploiter la vulnérabilité, elles devraient être décrites. Vient ensuite la description des détails techniques du bug, où nous montrons comment exploiter le bug. À la fin de cette partie du rapport d'audit de sécurité, nous devrions inclure les recommandations qui élimineront la menace une fois introduites.
Exemple de description d'une vulnérabilité
Niveau de la vulnérabilité : Critique
Identifiant de la vulnérabilité : FOO_BAR-API-000
Titre de la vulnérabilité : Mode administrateur disponible en ajoutant manuellement un cookie
Description
L'application d'autorisation administrateur utilise un cookie qui peut être obtenu par un attaquant. Le compte auquel on peut accéder de cette manière est désigné comme un compte en mode dieu par l'application.
Conditions nécessaires pour exploiter la vulnérabilité : Aucune
Détails techniques
L'attaquant doit ajouter à l'application un cookie avec les propriétés suivantes :
Nom : code
Valeur : iddqd
Recommandation
Mettre en place une autorisation de connexion et l'authentification à deux facteurs lors de l'accès à un compte en mode dieu. Supprimer l'autorisation via le cookie.
Rapport d'audit de sécurité – résumé
Suivre quelques règles simples vous permet de créer efficacement un rapport d'audit de sécurité clair et rempli d'informations pertinentes. Comme nous l'avons indiqué dans l'introduction, l'audit lui-même pourrait être réalisé de manière exemplaire. Cependant, si le rapport (le résumé du travail) n'est pas au même niveau élevé, le résultat de l'audit – c'est-à-dire toutes les conclusions tirées au cours de celui-ci, tous les commentaires et recommandations – peuvent ne pas être mises en œuvre correctement voire être complètement omises. Le rapport doit être rédigé à la fois de la manière la plus agréable et la plus factuelle. Nous devons également nous rappeler de l'aspect visuel d'un tel document, qui doit rendre l'ensemble esthétiquement agréable sans détourner l'attention du contenu.
Les conseils présentés dans cet article seront utiles lors de la préparation de documents après avoir réalisé des audits de divers types d'applications et de sites web, y compris ceux basés sur Drupal. Si vous avez besoin de conseils supplémentaires sur les rapports de sécurité d'applications dans ce cadre ou sur la réalisation d'un audit complet, découvrez-en plus sur notre équipe de support Drupal.
