Rapport D'audit

ARTICLE 1 : OBJET DE LA CONSULTATION

L’objet de cet audit devra se conformer, au minimum, aux dispositions énoncées dans le décret N°2004-1250 et être, au moins, piloté par, au moins, un chef de projet certifié par l’ANSI, conformément au décret N° 2004-1249 du 25 mai 2004.

La mission d’audit objet de cette consultation devra ainsi concerner les composants suivants : système d’exploitation, serveur web, serveur base de données, réseau d’hébergement et l’application web de l’ [entreprise].

ARTICLE 2 : PASSATION DE LA CONSULTATION

Les offres doivent parvenir sous pli anonyme au plus tard le ……/ ……… / ……… au bureau d’ordre central de [nom de l’organisme] au nom de monsieur à l’adresse suivante :

[Adresse de l’organisme]

(Le cachet du bureau d’ordre central faisant foi)

L’enveloppe extérieure doit comporter, outre l’adresse la mention :

«A NE PAS OUVRIR »

CONSULATION DE L’AUDIT SECURITE DE LA PLATEFORME WEB

ARTICLE 3 : INTERVENANT (S)

Chaque membre de l’équipe intervenante doit :

- Etre un expert auditeur en sécurité informatique (certifié par l’ANSI).

- Avoir un certificat d’expert auditeur valide

- Avoir effectué au moins une mission d’audit de site web.

- Avoir une expérience d’au moins une année dans le domaine de l’audit de la sécurité informatique et/ou l’audit des sites web.

ARTICLE 4 : CONDUITE ET DEROULEMENT DE LA MISSION

Cette mission sera décomposée en trois phases :

1. Phase de préparation de la mission

Une réunion préparatoire de la mission sera organisée au début de la mission, dont l’objet sera de finaliser, sur la base des besoins et documents préparés par le soumissionnaire, les détails de mise en œuvre de la mission.

Elle concernera, sans s’y limiter, la finalisation des détails suivants :

• Désignation des chefs de projets et des interlocuteurs, côté maître d’ouvrage et soumissionnaire.

• Fourniture des détails complémentaires relatifs au domaine de l’audit,

• Fourniture des documents requis pour l’audit (Document de conception de l’application web, schéma de la base de données, manuels d’exploitation, schémas d’architectures, …)

• Discussion sur les risques engendrés par l’audit (en cas ou la plateforme à tester = plateforme en exploitation). Pour cela, il fallait se mettre d’accord sur la plateforme à tester : est ce que les tests seront lancés sur la plateforme en exploitation ou bien une plateforme de test identique à la plateforme réelle sera préparée par le maître d’ouvrage.

• Fixation des dates de lancement des tests intrusifs ainsi que la durée dans la journée (Si les tests seraient effectués sur la plateforme en exploitation, il serait recommandé de lancer les tests lorsqu’il n’y a pas un nombre important de connexions sur le serveur web : la nuit par exemple, les jours de Week-end ).

• Examen des problèmes éventuels, relatifs à la mise à jour de la documentation,

• Affinement des plannings d’exécution (planning des actions, plannings des réunions de coordination et de synthèse, ….).

Ainsi tous les détails de mise en œuvre seront examinés et validés. Cette réunion débouchera, entre autre, sur la synthèse des plannings précis et détaillés de mise en œuvre de la mission.

2. Phase d’audit

La mission d’audit de la plateforme web doit passer obligatoirement par deux phases de Tests intrusifs (Pentest). Dans le cadre de la mission d’audit de la sécurité de la plateforme web, il est recommandé de commencer par un test intrusif en Boite Noire ensuite recourir à un Test Intrusif Boite Blanche :

2.1 Tests intrusifs en Boite Noire :

Durant cette phase l’auditeur n’a aucune information sur la plateforme web cible à part l’URL ou l’adresse IP du serveur web en se mettant en situation d'attaque réelle sans aucune connaissance préalable du système.

Ainsi, cette phase d’audit /pentesting couvrira principalement trois volets :

o Un volet de reconnaissance et de décomposition de l’application

Il s’agit de collecter le maximum d’informations sur la plateforme cible.

A travers ce volet, on essaye de décrire l’architecture globale de l’application (2 tiers, 3 tiers) et de définir les acteurs du système tout en identifiant les rôles correspondants. Ensuite, il faut déterminer les composants de la plateforme (systèmes d’exploitation (Windows, Unix), serveur web (Apache, IIS, etc), serveur base de données (MySQL, Oracle, SQL server, etc), technologie de développement (PHP, JSP, ASP, ASP.net, utilisation de CMS ou non, etc.), réseau d’hébergement, etc) et essayer de dresser l’architecture du front office (diagramme d’arborescence) et si possible celle du back office.

Au cours de cette étape, le soumissionnaire doit recourir à des outils de reconnaissance et de scan permettant l’identification et la décomposition de l’application. Ces outils de scan doivent être variés afin d’essayer le mieux d’identifier les différents composants de la plateforme.

De même, il devra emprunter une approche méthodologique, basée sur des batteries de questionnaires pré-établis (surtout pour ce qui concerne le réseau d’hébergement) et adaptés à la réalité des entités auditées.

En cas de difficultés notoires rencontrées lors de cette phase (surtout lors des interviews avec les différents intervenants), le soumissionnaire devra faire recours au Maître d’Ouvrage par écrit, pour permettre à celui-ci d’intervenir efficacement et dans les délais.

o Un volet d’analyse et identification des vulnérabilités potentielles

Ce volet concerne l’analyse des menaces et l’identification des vulnérabilités

...