Créer des standards de test pour vos Hacks éthiques - des mannequins

Une mauvaise communication ou dérapage dans vos normes de test peut envoyer les systèmes s'écraser pendant vos tests éthiques de piratage. Personne ne veut que cela arrive. Pour éviter les incidents, élaborez et documentez les normes de test. Ces normes doivent inclure

Lorsque les tests sont effectués, ainsi que la chronologie globale
Quels tests sont effectués
Combien de connaissances acquises à l'avance sur les systèmes
Comment les tests sont effectués et à partir de quelles adresses IP source
Ce que vous faites lorsqu'une vulnérabilité majeure est découverte

Passez vos tests

Ceci est particulièrement vrai lors des tests éthiques de piratage. Assurez-vous que les tests que vous effectuez minimisent l'interruption des processus métier, des systèmes d'information et des personnes. Vous voulez éviter les situations dangereuses telles que la mauvaise communication des tests et le déclenchement d'une attaque DoS contre un site de commerce électronique en plein milieu de la journée ou l'exécution de tests de mot de passe au milieu de la nuit.

Même avoir des personnes dans des fuseaux horaires différents peut créer des problèmes. Tout le monde sur le projet doit s'entendre sur un calendrier détaillé avant de commencer. Avoir l'accord des membres de l'équipe met tout le monde sur la même page et fixe les attentes correctes.

Votre chronologie de test doit inclure les dates et heures spécifiques à court terme de chaque test, les dates de début et de fin, ainsi que les étapes spécifiques entre les deux. Vous pouvez développer et entrer votre chronologie dans une feuille de calcul simple ou un diagramme de Gantt, ou vous pouvez inclure la chronologie dans le cadre de votre proposition initiale de client et de votre contrat. Votre calendrier peut également être des structures de répartition du travail dans un plan de projet plus vaste.

Exécuter des tests spécifiques

Vous avez peut-être été chargé d'effectuer un test de pénétration général, ou vous pouvez effectuer des tests spécifiques, tels que le cracking des mots de passe ou essayer de gagner accès à une application Web. Vous pouvez également effectuer un test d'ingénierie sociale ou évaluer Windows sur le réseau.

Quel que soit votre test, vous pourriez ne pas vouloir révéler les spécificités du test. Même lorsque votre manager ou client n'a pas besoin d'enregistrements détaillés de vos tests, documentez ce que vous faites à un niveau élevé. Documenter vos tests peut aider à éliminer toute mauvaise communication potentielle.

Vous connaissez peut-être les tests généraux que vous effectuez, mais si vous utilisez des outils automatisés, il peut être impossible de comprendre tous les tests que vous effectuez complètement. Cela est particulièrement vrai lorsque le logiciel que vous utilisez reçoit des mises à jour de vulnérabilité en temps réel et des correctifs du fournisseur chaque fois que vous l'exécutez.Le potentiel de mises à jour fréquentes souligne l'importance de lire la documentation et les fichiers fournis avec les outils que vous utilisez.

Évaluations des aveugles et des connaissances

Connaître les systèmes que vous testez peut être une bonne idée, mais ce n'est pas obligatoire. Mais, une compréhension de base des systèmes que vous pirater peut vous protéger et protéger les autres. Obtenir ces connaissances ne devrait pas être difficile si vous piratez vos propres systèmes internes.

Si vous trafiquez les systèmes d'un client, vous devrez peut-être creuser un peu plus profondément le fonctionnement des systèmes afin de vous familiariser avec eux. Cela ne signifie pas que les évaluations à l'aveugle ne sont pas utiles, mais le type d'évaluation que vous effectuez dépend de vos besoins spécifiques.

La meilleure approche consiste à planifier des attaques illimitées , dans lesquelles tout test est possible, voire même les tests DoS.

Déterminez si les tests doivent être effectués de manière à ne pas être détectés par les administrateurs réseau et les fournisseurs de services de sécurité gérés. Bien que cela ne soit pas obligatoire, cette pratique devrait être envisagée, en particulier pour les tests d'ingénierie sociale et de sécurité physique.

Emplacement

Les tests que vous effectuez dictent d'où vous devez les exécuter. Votre objectif est de tester vos systèmes à partir d'emplacements accessibles aux pirates informatiques ou aux employés. Vous ne pouvez pas prédire si vous serez attaqué par quelqu'un à l'intérieur ou à l'extérieur de votre réseau, alors couvrez toutes vos bases. Combiner des tests externes et des tests internes.

Vous pouvez effectuer certains tests, tels que la vérification des mots de passe et l'évaluation de l'infrastructure réseau, à partir de votre bureau. Pour les hacks externes nécessitant une connectivité réseau, vous devrez peut-être quitter le site ou utiliser un serveur proxy externe. Les scanners de vulnérabilité de certains fournisseurs de sécurité sont exécutés à partir du cloud, ce qui fonctionne également.

Mieux encore, si vous pouvez attribuer une adresse IP publique disponible à votre ordinateur, connectez-vous simplement au réseau à l'extérieur du pare-feu pour obtenir une vue hacker de vos systèmes. Les tests internes sont faciles car vous n'avez besoin que d'un accès physique au bâtiment et au réseau. Vous pourriez être en mesure d'utiliser une ligne DSL ou un modem câble déjà en place pour les visiteurs et les utilisateurs similaires.

Répondre aux vulnérabilités que vous trouvez

Déterminez à l'avance si vous allez vous arrêter ou continuer lorsque vous trouvez un trou de sécurité critique. Vous n'avez pas besoin de continuer à pirater pour toujours ou jusqu'à ce que vous plantez tous les systèmes. Suivez simplement votre chemin jusqu'à ce que vous ne puissiez plus le pirater. En cas de doute, la meilleure chose à faire est d'avoir un objectif précis en tête et de s'arrêter lorsque l'objectif a été atteint.

Si vous découvrez un trou majeur, contactez les bonnes personnes dès que possible afin qu'elles puissent commencer à résoudre le problème immédiatement. Les bonnes personnes peuvent être des développeurs de logiciels, des chefs de produit ou de projet, ou même des DSI. Si vous attendez quelques jours ou quelques semaines, quelqu'un pourrait exploiter la vulnérabilité et causer des dommages qui auraient pu être évités.

Hypothèses stupides

Vous avez entendu parler de ce que vous faites de vous-même lorsque vous assumez les choses. Même ainsi, vous faites des hypothèses lorsque vous piratez un système.Voici quelques exemples de ces hypothèses:

Les ordinateurs, les réseaux et les personnes sont disponibles lorsque vous testez.
Vous avez tous les outils de test appropriés.
Les outils de test que vous utilisez réduiront les risques de crash des systèmes testés.
Vous comprenez la probabilité que des vulnérabilités existantes n'aient pas été trouvées ou que vous ayez mal utilisé vos outils de test.
Vous connaissez les risques de vos tests.

Documentez toutes les hypothèses et demandez à la direction ou à votre client de les approuver dans le cadre de votre processus d'approbation global.