Comment savoir quand un test au stylo est terminé?
Considérant spécifiquement les sites Web des clients où l'on nous a demandé d'effectuer un test de plume; à quel moment nous arrêtons-nous et disons que nous avons terminé?
Nous avons accès à divers outils (certains automatisés, certains manuels); mais si nous disons "nous avons essayé tous nos outils et n'avons pas pu progresser", cela pourrait être interprété comme nous disant que nous ne sommes pas assez intelligents (et il y a toujours un pirate informatique qui pourrait être plus intelligent).
Donc; comment pouvons-nous nous protéger contre les clients contrariés qui prétendent que nous n'avons pas travaillé avec diligence raisonnable? Existe-t-il un cadre de rapport standard dans lequel nous pouvons travailler?
C'est donc en fait une question très intéressante pour l'industrie en général. La façon dont je vous suggère de le gérer est
Avoir quelque chose dans votre contrat qui décline toute responsabilité pour les vulnérabilités non notées lors des tests. La raison en est qu'il est pratiquement impossible de s'assurer que vous avez trouvé tous les problèmes exploitables sur un site Web ou tout autre système. Pour prendre un exemple, pensez à tous les sites qui étaient vulnérables à Shellshock pendant des années et des années. Est-ce que toutes les sociétés de stylos qui ont touché l'un de ces sites devraient être tenues responsables de ne pas en informer leurs clients?
Ayez une méthodologie, dites ce que vous allez faire. Cela devrait couvrir les domaines généraux des tests qui seront achevés. Pour les sites Web, envisagez de vous baser sur quelque chose comme le Top 10 de l'OWASP comme point de départ. Cela vous donne un terrain d'entente avec le client sur ce que vous allez regarder.
Assurez-vous que votre entreprise couvre les bases avec une liste de contrôle. comme le dit @rapli ci-dessus, documentez toutes les petites choses, mais ne surestimez pas la gravité. Bien qu'il soit important de vous assurer que votre test n'est pas juste une liste de contrôle, son utilisation peut éviter des erreurs embarrassantes lorsque les tests de base sont manqués.
Le problème que vous pourriez/rencontrerez est des attentes irréalistes des clients. celui-là est un cas à traiter. Si vous obtenez un client qui s'attend à ce que son application complexe soit complètement examinée en 5 jours-personnes de test, vous devriez expliquer pourquoi ce n'est pas un concept pratique :)
Spécifiez dans le contrat les aspects de sécurité que vous étudiez et n'en assumez la responsabilité. Vous ne trouverez pas toujours de vulnérabilités. Mais je vous garantis que vous trouverez peu de choses mineures, et je vous suggère d'inclure chaque petit détail que vous pouvez dans le rapport, HSTS manquant dans les en-têtes, chiffres faibles, etc. Ils voient donc que vous avez fait quelque chose.
Il existe certains outils de reporting que je connais, mais ce ne sont pas des produits payants ou accessibles au public.
En plus des autres réponses:
Lorsque votre contrat indique votre portée et les vulnérabilités à tester, vous pouvez noter que vous avez réellement testé les cas de portée par rapport aux vulnérabilités connues définies dans le contrat. Quelque chose comme:
SQL injection:
SQL-Injections are ...
We identified 42 Input fields in the Webpages in Scope. We identified 0
Input fields vulnerable to SQL injection (with our used method).
L'inconvénient est: dans le cas où il y a réellement une injection SQL possible dans l'un des champs répertoriés annexés au rapport; vous n'avez pas promis une sécurité à 100%, mais promis que ce n'est pas une vulnérabilité, mais vous avez sûrement fait quelque chose de mal - c'est pourquoi vous devez indiquer quel type de tests vous avez utilisé, quel type d'injections SQL sont à la pointe de la technologie dans l'introduction à SQL-Injections, vous ne serez donc pas blâmé de ne pas avoir trouvé d'attaques qui seront détectées à l'avenir.
Cela fonctionne également pour les éléments généraux de sécurité du site Web:
HTTPS: https is ... recommended to use TLS X.Y ...
We determined the usage of https for all websites in Scope with TLS X.Y.
Certificates expire Dates are set to Date X which is in the recommended
certificate expire time range. Certificates hold an 4096-Bit key which is
acceptable for current usage.
Essayez également de créer des modèles de vos rapports car vous ne voulez pas tout réécrire sur SQL-Injection et HTTPS/TLS etc., encore et encore, vous n'avez donc qu'à remplir les résultats de vos tests. Cela garantira également que vous avez fait tous les tests et que vous n'en avez raté aucun, lorsque vous voyez un paragraphe non écrit à faire et que vous n'avez rien trouvé ni aucune constatation.