Pourquoi attaquer ses propres systèmes

Télécharger au format docx, pdf ou txt
Télécharger au format docx, pdf ou txt
Vous êtes sur la page 1sur 5

Pourquoi attaquer ses propres systèmes ? Pour attraper un voleur, il faut penser comme un voleur.

Cet adage constitue le fondement des tests TVP. Il faut connaître son ennemi. Se contenter de
moyens et de statistiques est contraire à la sécurité. Les pirates sont de plus en plus nombreux et leur
niveau d’expertise ne cesse d’augmenter. Parallèlement, les points faibles des systèmes et les
faiblesses masquées ne cessent de se multiplier. Tout système informatique et toute application peut
finir par être piraté ou compromis. Il est donc essentiel de protéger votre système contre les pirates,
sans vous contenter d’appliquer les bonnes pratiques générales. Lorsque vous connaîtrez les
techniques des pirates les plus rusés, vous saurez à quel point vos systèmes sont vulnérables. Les
pirates cherchent d’abord à repérer les mauvaises pratiques en termes de sécurité et les points
faibles inconnus. Sont également visés les points faibles connus depuis longtemps, comme le
montrent de plus en plus d’études, par exemple l’étude annuelle de Verizon Data Brief Investigations
Report (www.verizonenterprise.com/verizon-insightslab/dbir). Par ailleurs, la mise en place de pare-
feu et du cryptage des données, sans compter d’autres technologies de sécurité (soidisant
fantastiques, mais également très coûteuses), donne souvent un faux sentiment de sécurité. Ces
solutions ont tendance à se concentrer sur les points faibles à haut niveau, comme le contrôle des
accès et la protection des données lors des transferts, sans s’intéresser à la façon dont opèrent
réellement les pirates. Pour rendre vos systèmes plus sûrs, vous devez essayer de les attaquer vous-
même, pour trouver les points faibles, notamment ceux qui sont les plus tentants. Les tests TVP
constituent une méthode éprouvée pour rendre vos systèmes vraiment plus robustes. Si vous laissez
un point faible inconnu, ce n’est qu’une question de temps avant que quelqu’un vienne en profiter.
Du fait que les pirates montent en compétence, vous devez vous aussi vous entraîner. Vous devez
vraiment adopter le même état d’esprit. Vous êtes un pirate éthique, vous devez connaître les
opérations que réalisent les pirates malveillants et comment leur barrer la route. Vous devez donc
savoir où chercher et comment exploiter les informations que vous recueillez. Ne cherchez pas pour
autant à protéger votre site ou votre système contre toutes les attaques, car c’est impossible. La seule
manière de vous protéger contre tout consiste à éteindre les ordinateurs et aller les enfermer dans un
coffre. Ce n’est évidemment pas la solution envisageable. Vous devez d’abord inventorier les
faiblesses connues et les attaques les plus répandues, c’est-à-dire les 20 % de problèmes qui
entraînent 80 % des risques. Bizarrement, dans de nombreuses entreprises, ce sont souvent les
faiblesses les moins prises en compte. Vous ne pouvez bien sûr pas prévoir tous les types d’attaques,
et surtout pas les techniques que vous ne connaissez pas encore. En revanche, plus vous tentez de
combinaisons et plus fréquemment vous testez vos systèmes de façon globale, plus vous aurez de
chances de découvrir des points faibles à large surface d’impact. N’allez pas inutilement loin dans vos
tests de sécurité. Protéger un système contre une attaque très peu vraisemblable n’a que peu de
sens. Voici les grands objectifs d’un test de sécurité. » Définir les priorités dans vos systèmes pour
pouvoir vous concentrer sur les points essentiels. » Tester les systèmes de façon non destructive. »
Dresser la liste des points faibles et trouver des arguments pour montrer à la direction qu’il y a des
risques pour l’entreprise. » Tirer des recherches un plan d’action pour éliminer les points faibles et
sécuriser les systèmes. Quels dangers guettent vos systèmes ? C’est une chose que de prendre
conscience que vos systèmes sont à la merci des pirates du monde entier autant que des utilisateurs
malveillants. C’en est une autre que de comprendre quelles attaques potentielles menacent vos
systèmes. Voici un aperçu général des attaques les plus répandues, présentation qui est loin d’être
exhaustive. Un bon nombre de points faibles au niveau sécurité ne sont pas critiques, pris isolément ;
en revanche, lorsqu’il est possible de cumuler la découverte de plusieurs points faibles à la fois, votre
système ou votre réseau est en danger. Le fait d’utiliser la configuration d’usine du système
d’exploitation Windows, de choisir un mot de passe facile à deviner pour l’administrateur d’une base
SQL Server ou de faire fonctionner un serveur sur un réseau sans fil ne constituent pas de gros
problèmes de sécurité pris un à un. Mais si quelqu’un réussit à exploiter ces trois points faibles à la
fois, il peut obtenir des accès distants non autorisés et subtiliser des informations confidentielles,
parmi d’autres menaces. La complexité est l’ennemi de la sécurité. Les possibilités d’attaque ont
énormément augmenté au cours des dernières années, suite à l’adoption de la virtualisation, des
ordinateurs distants en nuage et des réseaux sociaux. Ces trois nouveautés, à elles seules, ont
augmenté de façon énorme la complexité de vos environnements. Attaques non techniques Le
principal point faible de tout réseau ou ordinateur est l’être humain qui peut être manipulé. Par
nature, l’humain fait confiance, ce qui permet des méfaits appelés ingénierie sociale. Cela consiste à
tirer profit de la confiance que font naturellement les humains afin de leur soutirer des informations,
notamment par la méthode de l’hameçonnage avec des courriels frauduleux. Je présente dans le
Chapitre 6 la problématique de l’ingénierie sociale et comment protéger vos systèmes. Un mode
d’agression assez répandu consiste à pénétrer physiquement les systèmes d’information. Les pirates
entrent dans les bâtiments, dans les salles informatiques ou dans tout autre zone contenant des
données stratégiques puis volent des ordinateurs, des serveurs et autres équipements précieux. Nous
rangeons dans les attaques physiques, la fouille des poubelles d’entreprise qui permet de trouver des
mots de passe, des schémas de réseau et d’autres informations sensibles. Attaques de l’infrastructure
réseau Les attaques qui visent l’infrastructure d’un réseau sont assez simples à réaliser, puisque les
réseaux sont par essence presque tous accessibles depuis n’importe où dans le monde par Internet.
Voici quelques exemples d’attaques de l’infrastructure réseau : » pénétration d’un réseau en passant
par un point d’accès sans fil non sécurisé situé derrière un parefeu ; » exploitation des faiblesses dans
les protocoles réseau, comme le protocole FTP de transfert de fichiers ou le protocole SSL ; »
engorgement d’un réseau avec un grand nombre de requêtes, ce qui crée une impossibilité d’accès
par déni de service (DoS) ; » implantation d’un analyseur réseau sur un segment d’un réseau pour
capturer tous les paquets de données qui y transitent et récupérer des informations confidentielles
non codées. Attaques des systèmes d’exploitation Les pirates aiment beaucoup s’attaquer aux
systèmes d’exploitation, tout simplement parce que tout ordinateur en possède un. Les systèmes
d’exploitation offrent de nombreux points faibles, certains connus depuis des années et toujours non
résolus. Certains systèmes d’exploitation sont plus robustes dès le départ, et notamment le bon vieux
système réseau Novell NetWare, ainsi qu’Open BSD et le système IBM Series i. Lorsque ces machines
sont attaquées, des points faibles sont mis au jour. Mais en général, les pirates préfèrent attaquer les
systèmes les plus répandus que sont Windows, Linux et Mac OS. Voici quelques genres d’attaque d’un
système d’exploitation : » exploitation des correctifs non installés ; » attaque des systèmes
d’authentification interne ; » contournement de la sécurité du système de fichiers ; » découverte des
mots de passe et décryptage trop faible. Attaques des applications Les applications constituent une
autre cible favorite des pirates. Les plus visées sont les applications Web et celles pour appareils
mobiles. Voici quelques exemples d’attaques applicatives avec les bénéfices qui en sont retirés,
notamment dans les réseaux d’entreprise : Applications Web. De nos jours, des applications Web sont
déployées dans tous les départements d’une même entreprise, sans concertation. Certaines sont
implantées à distance dans le cloud. Cette dispersion correspond au concept de Shadow IT. De
nombreux professionnels de l’informatique et de la sécurité ne sont même pas informés de ces
utilisations personnelles de l’informatique et des risques qu’elles entraînent. Applications mobiles.
Les attaques se multiplient à destination des terminaux mobiles, qui sont de plus en plus utilisés en
entreprise. Les magasins applicatifs App Store et Google Play contiennent quelques applications
malveillantes. Des fichiers non sécurisés contenant des informations confidentielles sont distribués
parmi les stations et les serveurs ainsi que dans le cloud, par exemple sur OneDrive ou Google Drive.
Les systèmes de bases de données contiennent aussi de nombreux points faibles. Précautions dans
les évaluations de sécurité Les professionnels de la sécurité doivent donc réaliser les mêmes attaques
de leur système que les pirates. Seul le résultat diffère, car il est question ici de découvrir les points
faibles. Nous verrons en détail comment réaliser ces exercices d’attaque dans les Parties 2 à 5 du
livre, et nous découvrirons comment mettre en place des mesures pour vous protéger. Pour qu’un
test de sécurité soit réalisé de façon professionnelle, il faut adopter quelques grands principes que je
présente dans la suite. Vous allez devant de graves mésaventures si vous ne vous tenez pas à ces
principes. J’ai vu des services informatiques les ignorer ou les oublier tout en exécutant les tests de
sécurité. Le résultat n’était pas beau à voir, croyez-moi. Travailler de façon éthique Dans notre
contexte, le terme éthique suppose de travailler avec de hautes valeurs morales et de façon
professionnelle. Que vous réalisiez les tests pour vos propres systèmes ou pour un client, toutes vos
actions doivent être irréprochables et totalement en phase avec les besoins de l’entreprise. Vous ne
devez pas avoir d’agenda caché. Être éthique signifie que vous rendez compte de tout ce que vous
trouvez, même si certaines découvertes risquent d’avoir un impact politique. Ne minimisez pas ce
dernier point : j’ai souvent vu des personnes masquer certaines découvertes, par peur d’être à
l’origine d’un scandale ou de devoir se confronter avec la direction ou des fournisseurs peu
coopératifs. Vous devez susciter et mériter la confiance que l’on place en vous. C’est la meilleure
méthode pour faire se rallier les clients ou collègues de votre côté pour qu’ils vous soutiennent à long
terme votre programme de test de sécurité. Il est absolument interdit de tirer profit des informations
et des pouvoirs qui vous sont concédés. C’est ce que font les pirates malveillants. Laissez-les finir en
prison. N’oubliez pas que vous pouvez être éthique sans être digne de confiance, et vice versa. Voyez
par exemple l’histoire d’Edward Snowden. Les dilemmes moraux auxquels vous devrez peut-être faire
face font partie des défis à relever. Je ne vous envie pas pour cette partie de votre travail. Respecter la
vie privée Vous devez respecter absolument les informations que vous collectez pendant vos tests,
qu’il s’agisse du contenu des applications Web, des mots de passe de messagerie et autres
informations personnelles. Tout doit être conservé avec la plus grande confidentialité. Ne tirez jamais
profit de votre accès aux informations confidentielles de l’entreprise ou à la vie privée des salariés.
Faites participer d’autres personnes à vos travaux. Mettez en place des réunions ou une procédure de
comptes-rendus périodiques afin de renforcer la confiance et de susciter le soutien pour vos projets
d’évaluation de la sécurité. Ne pas malmener les systèmes Une des plus grosses erreurs que j’ai vu
faire par des gens se lançant dans les tests de sécurité était de provoquer l’arrêt des systèmes qu’ils
analysaient. Ces plantages de systèmes ne se produisent plus aussi aisément que dans le passé, grâce
à la plus grande robustesse des systèmes actuels, mais une mauvaise planification peut avoir des
conséquences néfastes. Même si vous ne le voulez évidemment pas, vous pouvez provoquer un
engorgement DoS d’un système en le testant. Vous bloquez un système facilement en lançant un trop
grand nombre de tests à la fois, ce qui entraîne des altérations des données, des redémarrages
intempestifs et autres problèmes, notamment avec les serveurs qui datent un peu ou les anciennes
applications Web. Je sais de quoi je parle, parce que cela m’est arrivé ! Ne croyez jamais qu’un réseau
ou qu’une machine hôte sera capable de tenir la charge que lui impose un outil d’analyse réseau.
Vous risquez même de bloquer un compte ou tout un système avec un analyseur de vulnérabilité ou
en demandant à une personne de changer son mot de passe sans tenir compte des conséquences.
Procédez avec bon sens. Cela dit, s’il y a une faiblesse à trouver, il est toujours préférable que vous la
trouviez en premier ! La plupart des outils d’analyse permettent de choisir le nombre maximal de
tests à réaliser sur chaque système à chaque instant. Ce paramétrage est très utile lorsque vous devez
effectuer les tests sur des systèmes en exploitation pendant les heures de travail. N’hésitez jamais à
réduire le nombre d’analyses simultanées. Vos tests prendront plus de temps, mais vous éviterez de
provoquer une instabilité système et de recevoir les plaintes qui vont en découler. Présentation des
tests TVP Comme pratiquement tout projet concernant l’informatique, vous devez planifier vos tests
de sécurité. Vous connaissez l’adage : « agir sans planifier c’est planifier son échec ». Les aspects
essentiels, tant au niveau stratégique que tactique, doivent être déterminés d’avance. Pour garantir le
succès de votre travail, prenez le temps de planifier vos tests, qu’il s’agisse de celui des mots de passe
sur quelques serveurs ou d’un test de pénétration d’un environnement Web complexe. Soyez vigilant
si vous décidez d’embaucher un pirate repenti pour vous assister pendant les tests ou pour obtenir
ses conseils. Je présente dans le Chapitre 19 les avantages et inconvénients qu’il y a à faire appel à
des ressources externes au niveau des tests de sécurité. Créer un plan de test Il est essentiel d’obtenir
l’approbation de vos supérieurs pour vos tests de sécurité. Vous devez être certain que ce que vous
allez faire est connu et visible, au moins aux yeux des décisionnaires. Il faut commencer par obtenir le
soutien des sponsors. C’est l’occasion de définir les objectifs de vos tests. Comme sponsors, il peut
s’agir de votre supérieur, d’un directeur, de votre client ou de vous-même si vous êtes à votre
compte. Il faut que quelqu’un soit certain de vous soutenir et accepte votre plan. Si vous ne prenez
pas cette précaution, vos travaux pourraient être interrompus à tout moment si quelqu’un, par
exemple, un fournisseur de services cloud ou un hébergeur, venait se plaindre du fait que vous n’avez
jamais été autorisé à réaliser ces tests. Vous pourriez même être remercié ou poursuivi pour activités
criminelles. L’autorisation qu’il vous faut peut dans certains cas se résumer à un compte-rendu de
réunion signé ou un courriel de votre patron, si les tests concernent vos propres systèmes. Si vous
travaillez pour un client, il faut obtenir un contrat signé qui mentionne clairement que le client
soutient et autorise vos travaux. Obtenez le plus tôt possible ce parrainage afin de ne pas travailler
inutilement. Ce document constituera peut-être votre carte magique pour passer à la banque sans
passer par la case prison, au cas où un fournisseur d’accès Internet, un fournisseur de services cloud
ou un sous-traitant se plaindrait de vos activités. Sans compter les instances gouvernementales qui
s’y intéressent. Ne riez pas ; ce ne serait pas la première fois que cela arrive. Une fausse manœuvre
peut planter un système, et personne ne le désire. Il nous faut donc un plan détaillé. Cela dit, n’allez
pas jusqu’à écrire des tomes entiers de procédures de tests qui rendraient le plan trop complexe.
Voici les informations qui doivent absolument faire partie de votre plan : » Choix des systèmes et
fonctions à tester. Commencez toujours par les systèmes et les processus les plus critiques, ou qui
vous semblent les plus fragiles. Vous pouvez commencer par tester les mots de passe d’accès au
système d’exploitation des serveurs, tester d’abord une application Web ou commencer par faire de
l’ingénierie sociale en lançant des courriels d’hameçonnage, et continuer par les autres éléments de
votre nouveau système. » Définition d’un plan de reprise et évaluation des risques. Prévoyez un plan
d’urgence au cas où vos tests de sécurité entraîneraient des dégâts. Imaginez que vous deviez tester
une application Web ou un pare-feu et que vous provoquez un blocage. Il en résulterait une
indisponibilité du système et une chute de la productivité des salariés. Vous pourriez même entraîner
des pertes de données et endommager l’image de l’entreprise. Des responsables seront recherchés,
et vous ferez sans doute pâle figure. Il s’agit donc d’évaluer les risques de vos tests. Prenez donc vos
précautions, surtout avant de procéder à de l’ingénierie sociale ou de lancer une attaque massive de
type DoS. Évaluez l’impact que vos actions auront sur les personnes et les systèmes. » Planification
des dates des tests et de leur durée. Pensez longtemps à l’avance aux dates appropriées pour lancer
vos tests. Soit vous les lancez pendant les heures de travail, soit vous ne les démarrez que la nuit ou
tôt le matin pour avoir moins d’impact sur les systèmes. Demandez l’avis autour de vous et faites en
sorte que vos choix de dates conviennent aux autres. Même si vous devez en subir, et en faire subir,
les conséquences, il est préférable de ne pas limiter les heures de vos attaques. En effet, les vrais
pirates ne vont pas tenter de s’introduire dans le système seulement pendant les heures de repos. Ne
réservez pour les heures de faible activité que les tests d’engorgement DoS, ceux d’ingénierie sociale
et les tests de sécurité physique. » Choix entre furtivité et visibilité. Vous préférez peut-être pouvoir
réaliser vos tests sans être détecté, en travaillant à distance, sans que les utilisateurs soient avertis. Si
vous les prévenez, les utilisateurs ou le service informatique vont se méfier et montrer leurs meilleurs
comportements au lieu d’opérer comme ils en ont pris l’habitude insouciante. » Choix de laisser actifs
les contrôles de sécurité. Un point souvent oublié concerne les éléments de sécurité tels que les pare-
feu réseau, les systèmes de prévention d’intrusion IPS et les pare-feu des applications Web qui sont
capables d’interdire les analyses réseau et les tentatives d’accès. Si vous maintenez ces mécanismes
actifs, vous obtenez une image réaliste de l’état du système, mais j’ai constaté qu’il était beaucoup
plus instructif de désactiver ces mécanismes, ou d’ajouter votre adresse IP en liste blanche, car c’est
ainsi que vous allez pouvoir trouver le plus grand nombre de failles. Nombreux sont ceux qui veulent
maintenir les mécanismes de sécurité actifs, puisque cela permet d’obtenir de meilleurs résultats à la
fin des tests. Personnellement, je ne nie pas l’intérêt de cette approche défensive, mais elle peut faire
naître un faux sentiment de sécurité et ne donne pas accès à une image complète du niveau de
protection général d’une organisation. » Reconnaissance ou non des cibles du test. Il n’est pas
nécessaire d’accumuler au préalable une connaissance fouillée de vos cibles. Il vous suffit d’en
connaître les grandes lignes, afin de vous protéger et de protéger les cibles.

Vous aimerez peut-être aussi