Pentest #1 - La préparation de l'audit

Par @Quack1 dans le
Tags : #Préparation, #Pentest, #Serie Pentest,
Partagez cet article! ~ Google+ ~ ~ Linkedin ~ Mail
Flattr this

Premier article de ma série consacrée aux "audits de la sécurité d'un système d'information" ou, terme plus courant, tests d'intrusion. :-)

 

La préparation d'un test d'intrusion est sûrement une des plus importantes de l'audit, et cela pour une raison simple : c'est à ce moment là que l'on rencontre le(s) client(s).

La rencontre avec le client est nécéssaire pour 2 raisons simples :

  1. Premièrement, il doit nous expliquer ce qu'il veut que l'entreprise audite, dans quelles conditions, et quels résultats il attend ;
  2. Ensuite, vient une raison plus terre-à-terre : comme dans toutes la plupart des entreprises, on ne travaille pas simplement parce que l'on veut travailler, sans ce soucier de l'argent qui rentre dans les caisses. On cherche un minimum à faire gagner de l'argent à notre société. On ne peut donc pas auditer le SI d'une société sans définir le prix (souvent au forfait /jour) de l'audit.

 

Dans ce chapitre, je n'aborderai pas le second point (je ne suis pas auditeur professionnel, et n'ai donc aucune idée de la moyenne des tarifs pratiqués par les sociétés d'audit). Je rentrerai simplement dans les détails de la préparation de l'audit, au moyen des diverses réunions avec le client. Enfin, j'aborderais *les contrats, documents et démarches qu'il est nécéssaire d'entreprendre afin de pratiquer l'audit dans un cadre légal bien défini.

 

Se faire auditer : pourquoi ?

À l'heure de l'"hyper-informatisation", je pense qu'il n'y a pas (ou très peu) d'entreprises qui ne possèdent aucune donnée stockée informatiquement. Toutes ses données, en rapport avec la société, sont ce que l'on nomme, dans le milieu du management de la sécurité, des biens. Dans beaucoup d'entreprises, généralement les petites et moyennes entreprises, on consacre très peu de temps et de personnels à la sécurisation de ces biens, pour la raison simple que cela coûte de l'argent et qu'il faut que tout soit fonctionnel le plus vite possible pour obtenir des bénéfices.

Cependant, on oublie également souvent que ces données sont essentielles pour la société. En effet, la recette secrête de la dernière boisson à la mode, le process de fabrication d'un nouveau produit sur un quelconque marché, ou tout autre type de données peut permettre à une entreprise concurrente, si elle venait à entrer en possession de cette information, de nous passer devant en vendant le même produit que nous sans avoir eu à le développer.

On se rend bien compte qu'une telle situation pourrait porter préjudice à la chère petite entreprise que M. Michu (oui, le mari de la Mme. du même nom ;-) ) a porté sur ses épaules toutes ses années...

On voudrait donc que les biens de cette entreprise soient sécurisés. Mais, question également très importante, que signifie le fait que des données soient sécurisées ?

 

Au niveau de la RSSI, ou Responsabilité de la Sécurité des Systèmes d'Information, assurer la sécurité des données consiste à garantir 3 propriétés pour nos informations :

  • Intégrité : Les données ne peuvent être modifiées que par des utilisateurs autorisés ;
  • Confidentialité : Les données ne peuvent être lues que par des utilisateurs autorisés ;
  • Disponibilité : Les données doivent à tout moment être accessibles pour les utilisateurs autorisés.

Si, à un moment ou à un autre, vous perdez une de ces 3 caractéristiques, alors vous pouvez affirmer que votre sécurité est compromise.

 

Cependant, c'est quand même un peu con de devoir attendre de se faire attaquer pour se rendre compte que la sécurité de son SI laisse à désirer. C'est pour cette raison simple qu'il est important de procéder à des tests d'intrusion. De cette façon, des auditeurs réaliseront dans des conditions très précises (voir plus bas) au état des lieux des faiblesses de votre système d'information. Les auditeurs vont pendant un laps de temps donné tenter d'attaquer le système afin de trouver les failles qui pourraient s'y trouver afin de permettre aux administrateurs et développeurs de les combler pour que des attaquant mal intentionnés ne puissent les utiliser.

 

Il faut en revanche garder une bonne chose en tête : un audit ne sera en aucun cas totalement exhaustif. L'audit ne durant qu'un temps limité, il sera impossible de couvrir la totalité du SI dans l'audit.

Il faudra donc, avant le début de l'audit, que les auditeurs et la société auditée se mettent d'accord sur la durée de l'audit et sur ce qui sera audité.

 

Auditer, oui, mais auditer quoi ?

Comme je vous l'ai dit précédemment, il est très important pour l'entreprise et les auditeurs de se mettre d'accord à l'avance sur plusieurs points :

  • Qu'est ce que l'entreprise veut auditer ? (Site, réseau, système, ...)
  • Quel est le périmètre à auditer ? (urls, machines, adresses IP, ...)
  • Quelle est la durée de l'audit ?

La portée de l'audit

Il est primordial pour la société qui se fait auditer de préciser à la société auditrice ce qu'elle veut faire certifier. En effet, il est possible de n'auditer que la dernière application Web que l'on a sorti, ou bien de ne vouloir obtenir que le niveau de sécurité des ordinateurs portables Windows de nos commerciaux. Pour des raisons, souvent de temps ou d'argent, une entreprise pourra préférer réaliser un audit en plusieurs temps, en séparant à chaque fois chaque secteur du système d'information, à savoir les applications Web, puis les serveurs ou le réseau et enfin les postes clients des utilisateurs.

Cependant, je pense que cette façon de faire n'est pas la meilleure : les failles sont souvent dûes aux interactions entre les différentes parties du système. Pour preuve, une base de données, si elle est configurée pour n'être accessible que depuis des adresses IP des serveurs connus (typiquement, l'interface locale (127.0.0.1) et l'adresse IP du serveur Web) ne pourra pas être compromise (puisque non accessible) via Internet.

De la même façon, une SQL Injection sur une application Web n'a aucun intêret. L'objectif est de compromettre la base de données et/ou de récupérer des informations depuis la BDD via l'application Web.

On se rend compte que n'auditer qu'une partie restreinte du Système d'Information (exemple : la sécurité des serveurs de données, non connectés à Internet) peut vite être inutile puisqu'on aboutira à un système sécurisé, alors qu'un autre audit (par exemple, la sécurité physique des installations) pourra mettre à mal toute la sécurité précdemment affirmée.

Le périmètre de l'audit

Cette partie est très importante, puisqu'elle est liée à la législation et aux droits et devoirs des auditeurs.

Il faut, dès le début, que les deux acteurs en place délimitent très clairement les parties du système sur lesquelles la société auditrice pourra lancer des attaques. Dans le désordre, et de façon non exhaustive, les choses à définir sont :

  • Pour une application Web : Les urls, à quelles parties du SGBD peut-on toucher (Tables, Bases de données, Logiciel), doit-on auditer la configuration du serveur Web et de l'OS de la machine ?
  • Pour un système "complet" : Adresses IP des machines, OS, postes clients et/ou serveurs, configuration des logiciels.
  • Pour un réseau : Points d'accès, méthodes d'authentification, firewalls.

Dans chacun des cas, on veillera à prévoir si un audit "physique" (accès physique aux machines/données et social engineering) doit/peut être effectué ou non.

Je viens de vous affirmer en début de cette partie que définir le périmètre etait très important, mais je ne vous ait pas dit pourquoi. Et bien il faudra attendre encore un peu!

WAIT ! WHAT ?!?

Bon, puisque vous insistez, je vais vous le dire tout de suite! ;-) Tout ceci est lié aux droits et aux devoirs des pentesteurs. Lors de l'audit, de très nombreuses attaques vont être menées sur le système audité. Comme vous le verrez dans la dernière partie de cet article, il existe en France plusieurs lois qui régissent et empêchent les attaques contre des systèmes informatiques.

Définir un périmètre permet de protéger les auditeurs face à des attaques en justice de la part de la société auditée. Si des attaques sont menées sur des applications/parties citées dans le contrat d'audit, il n'y aura aucun risque de problèmes judiciaires, puisque l'entreprise qui se fera attaquer aura accepté via le contrat de subir des attaques dans le cadre d'un audit.

En revanche, toute attaque dans une partie du système qui n'a pas été clairement spécifiée pourra faire l'objet d'une plainte/procès pour cause d'Intrusion dans un Système Informatique.

_Notez qu'il faudra également déterminer dans le contrat d'audit quelles seront les adresses IP utilisées lors des attaques afin de séparer les attaques "autorisées" des "véritables" attaques.

 

Quels droits et quels devoirs pour chacun ?

Comme j'ai commencé à vous le dire dans les 2 parties précédentes, les auditeurs ont des droits et des devoirs précis pour mener à bien l'audit.

La rédaction d'un contrat d'audit est indispensable et permet de définir de façon claire ce qui pourra ou non être fait par les différentes parties. N'étant absolument pas expert dans ce domaine, je préfère vous renvoyer au bon article d' @Tris_Acatrinei.

Concernant la législation en vigueur au niveau des attaques, il est peut-être intéressant de lire les articles 323-1, 323-2, 323-3 et 323-3-1 du Codé Pénal. Cependant, si vos audits sont réalisés dans les règles, vous ne devriez pas souffrir de ces articles :-)

Je n'ai pas énormément plus d'informations à ce sujet, puisque si vous avez un contrat qui définit clairement ce qui est autorisé ou non, et que vous le respectez à la lettre, vous n'aurez aucun souci à vous faire!

 

Ceci signe la fin de cet article sur les test d'intrusions, et j'espère que j'aurai abordé tous les points qui touchent à la préparation de l'audit d'un Système d'Information. Si vous souhaitez obtenir plus d'informations, n'hésitez pas à me contacter via twitter ou par mail, au besoin en utilisant GPG

On se retrouve pour de nouvelles aventures sur le pentest avec un nouvel article sur la reconnaissance passive des cibles, j'espère avant 2013 ;-)

 

Image d'en-tête

Cet article est libre et diffusé sous une licence Creative Commons CC-BY-NC. Vous pouvez rémunérer son auteur en utilisant le système Flattr :
Flattr this

Comments !