Pour illustrer le scénario, il faut modéliser le système d'information de l'agence de sous-traitance à l'aide d'une architecture type. La principale limitation de ce genre de maquette est l'absence d'une population suffisante d'acteurs sur le système d'information. En effet, plus la population d'utilisateurs est importante, plus l'ingénierie sociale est pertinente et efficace.
Pour rendre cette maquette de système d'information «réaliste», il est nécessaire d'introduire quelques biais :
- La population des utilisateurs est limitée
-
La maquette est une réduction minimaliste de système d'information. Il lui manque une population d'utilisateurs suffisante pour générer un trafic aléatoire permanent. Ce sont ces flux réseaux qui servent de «bruit de fond» pour camoufler les tentatives d'intrusion dans le système. Toute la difficulté, dans l'analyse des flux d'un véritable système d'information, est de distinguer un trafic réseau «normal» d'un trafic intrusif. A ce «bruit de fond» il faut ajouter toutes les tentatives d'intrusion leurres qui génèrent de fausses alertes : virus, vers, etc.
Pour les travaux de groupes, le seul moyen d'analyse comparative envisagé consiste à confronter les données recueillies par plusieurs outils sur des postes raccordés au réseau public. De cette façon, après quelques semaines de collecte, on dispose d'un volume conséquent de «bruit de fond» et de leurres que l'on peut étudier en vis à vis des informations collectées sur la maquette.
- La population des utilisateurs est singulière
-
Comme les rôles des groupes d'étudiants sont biens définis au départ, il reste peu de place pour les surprises. Le comportement de chacun vis à vis du système d'information est facile à prédire. On imagine mal que le rédacteur de la politique de sécurité sur le courrier électronique se mette à l'enfreindre en quelques minutes. Il est donc très difficile d'introduire un utilisateur véritablement étranger à l'architecture du système d'information et, en plus, de lui laisser le temps de prendre des initiatives originales.
- La dérive des usages
-
Comme la durée du cours est limitée à quelques semaines, il est difficile d'imaginer une dérive des usages et de la configuration du système d'information par rapport aux politiques de sécurité définies. C'est pourtant une des principales pistes d'exploitation pour les tests d'intrusion.
Lors des tests pratiques, il faut disposer d'au moins un serveur et un poste de travail sur lesquels la dérive est simulée en n'installant pas tous les correctifs nécessaires et conformes aux définitions des politiques de sécurité. De la même façon, on simule les prestations de services «bancales» des opérateurs en programmant des «temps d'absence» sur le pare-feu de la maquette.