Rechercher
Contactez-nous Suivez-nous sur Twitter En francais English Language
 











Abonnez-vous gratuitement à notre NEWSLETTER

Newsletter FR

Newsletter EN

Vulnérabilités

Se désabonner

Keross : Pourquoi procéder à des Tests d’intrusion ?

février 2010 par Keross

Vous connaissez l’histoire. À mi-chemin vers l’aéroport votre épouse vous demande soudainement : « Es-tu sûr d’avoir fermé la fenêtre ? Je ne voudrais pas passer mes vacances à penser aux cambrioleurs. » Et vous êtes sûr. Vraiment sûr. Enfin, sûr à 99%. Est-ce que vous devriez faire demi-tour et vérifier ? Non, ce serait céder à la paranoïa. Ça va aller. Sûrement.

Les chefs d’entreprise et managers IT savent bien ce que sait. Est-ce que notre système de vente en ligne est vraiment sécurisé ? Qu’en est-il des fichiers du personnel ? Des données financières ? Est-ce que les pirates pourraient trouver une vulnérabilité ? Est-ce que le personnel interne pourrait accéder à plus que ce qu’il devrait ? Existent-ils des portes dérobées utiles à la maintenance mais connues par une personne qui ne devrait pas ? Rares sont les managers IT qui ne se sont pas penchés longuement sur la question de sécurité. Et pourtant, rares sont les managers qui affirmeraient posséder un système infaillible en y mettant leur main à couper.

Le piratage de ses propres systèmes : le hic

Il en résulte qu’une industrie toute entière s’est créée autour de la surveillance de la sécurité. Mais déjà, un dilemme se pose. Est-ce qu’il faut aller trouver une société inconnue et leur demander de s’infiltrer dans notre sécurité ? Et s’ils trouvaient une faille ? Est-ce qu’ils vont nous le dire, ou bien vont-ils s’en servir contre nous ? Et si les tests en eux-mêmes venaient à causer des problèmes ?

Alors peut-être vaudrait-il mieux faire les tests en interne ? Mais si l’on y réfléchit bien, les départements IT internes sont en fait les moins bien placés pour tester leur propre sécurité. S’il y a un problème, c’est justement parce que nous avons omis quelque chose. Par définition, nous serions moins à même d’y penser maintenant plutôt qu’une personne qui se pencherait sur le problème pour la première fois.

Une solution équilibrée

Alors, il est vraiment judicieux de passer en externe pour effectuer le test, mais vous avez besoin d’un partenaire doté d’une réputation bien établie et d’un test bien défini, digne de confiance. C’est parce que Keross gère des systèmes au nom d’autres entreprises, que nous avons pensé à ça dès le début et que nous avons développé un protocole précis.

1. Définition des risques à tester. Les risques les plus courants sont :
• Faiblesses techniques (piratage, exposition accidentelle)
• Manque de gouvernance sécurisée (procédures internes déficientes)

2. Définition des tests à effectuer.
• Les faiblesses techniques sont abordées selon un processus à 3 étapes, pour répondre aux questions suivantes :
1. Est-il possible d’identifier l’IP, le système d’exploitation ou autre logiciel ?
2. Quels systèmes ou services de votre société peuvent être identifiés par ce logiciel et cette adresse IP ?
3. Est-il possible de pirater la sécurité de ces systèmes et/ou services, et en particulier le transfert des données entre systèmes ?
• Problèmes liés à la gouvernance
Un audit ISO 27001 est effectué. Si l’entreprise est déjà conforme, un audit viendra tester cette conformité. Si elle n’est pas encore conforme, le client sera guidé à travers les étapes de conformité.

3. Effectuer des « attaques » prévues
Nous suggérerons des « attaques » spécifiques sur le système, en simulant des comportements de piratage avec des effets possibles bien déterminés (par exemple : qu’une donnée particulière puisse être inspectée, insérée, supprimée ou modifiée). Ceci est effectué en collaboration avec le département IT interne accompagné d’un technicien KEROSS sur place.
Les attaques ne sont pas toutes dissimulées. Nous pouvons également tester des attaques de « force brute ». Et si votre entreprise venait à se faire un ennemi, peut-être un ancien employé qui vous en veut ? Est-ce que vos systèmes pourraient être immobilisés par déni de service ?
Il est impératif que tous ces tests soient réalisés d’une manière prédéfinie, avec un impact connu. Nous ne ferons jamais de test d’intrusion sans expliquer l’ampleur de l’impact potentiel et sans approbation explicite de notre client.

Test du système d’authentification

Le risque le plus courant n’est pas l’œuvre du pirate ado isolé dans la pièce du fond. La plupart des atteintes à la sécurité sont plutôt dues à un manque d’authentification sécurisé. Nous évaluerons donc l’opacité de votre système : jusqu’à quel niveau un intrus pourrait-il déterminer comment les utilisateurs s’identifient ? Nos compétences spécialisées dans ce domaine nous permettrons de vous aviser si vous employez des procédures ultramodernes. S’il faut choisir entre commodité et sécurité, quel risque prenez-vous en simplifiant légèrement l’authentification ? L’objectif n’est pas de tout compliquer, mais de vous apporter de la transparence là où des risques existent, ainsi que les mesures que vous pourriez adopter.

Résultat des courses

Le résultat sera pour vous de connaître le niveau de votre profil risque par rapport aux normes de l’industrie dans les domaines suivants :

• Sécurité du système
• Configuration des services
• Protection de l’image
• Politique de filtrage
• Sécurité au niveau des applications
• Opacité globale

Le coût généré par ce type d’audit de sécurité est bas : c’est une tâche que nous effectuons régulièrement, nous pouvons donc le faire rapidement et efficacement. Vous en tirez une garantie pour vous et pour les clients qui comptent sur vous. Il ne s’agit pas de piéger le département IT, mais de confirmer par une étude indépendante que tout a bien été couvert. Oui, vous aviez bien fermé la fenêtre. Ou peut-être que vous aviez bien fermé la fenêtre en question, mais qu’il existe une autre fenêtre que les dernières techniques peuvent déceler, et qui a aussi besoin d’être fermée.


Voir les articles précédents

    

Voir les articles suivants