 |
Proposition de sujets de stage |
(ouvert à candidature)
Conception d'un site web
sécurisé d'enchères inversées
Conception d'un outil de
traduction automatique d'une conception UML en
architecture sécurisée
Évaluation des performances d'une
amélioration d'IPSec qui tient en compte la QoS
Identification des modes de
defaillances de snort
 |
| Durée : 4 à 6 mois | Mots clés : Web 2.0, php, sécurité des applications web |
Dans les applications d'enchères traditionnels, le vendeur propose son produit et les acheteurs potentiels enchérissent.
Le but de ce travail est de faire l'inverse. Il s'agira donc de concevoir un site web ergonomique où les acheteurs peuvent se mettre en communautés pour proposer des produits.
Plus nombreux ils seront, mieux ils pourront faire pression sur les vendeurs.
Ensuite, quant l'enchère inversé est ouvert, les vendeurs peuvent enchérir pour proposer des les meilleurs prix pour les produits demandés, compte tenu du nombre d'acheteurs potentiels (i.e., la communauté créée avant le lancement de l'enchère inversé).
La deuxième étape consiste à faire une analyse des risques (identifier les menaces et vulnérabilités) et d'intégrer à notre site les solutions de sécurité les plus appropriées. .
|
| Durée : 4 à 6 mois | Mot clés : Contrôle d'accès, UML, J2EE ou .Net |
Malheureusement, la sécurité est souvent considérée comme une fonctionnalité qu'on rajoute une fois le système (ou le logiciel) est en exploitation. Néanmoins, la construction d’architectures complexes nécessite une certaine méthodologie concrète et précise, où la sécurité doit être intégré, de préférence, dès les premières phases de la conception.
Des travaux existants ont déjà traité et implémenté architecture basée « modèle » dans les systèmes où les droits sont attribués aux utilisateurs selon les rôles qu'ils jouent dans le système. Ce type d'outils offre la possibilité de modéliser des systèmes intégrant la sécurité au modèles conceptuels du système.
Le travail qui sera traité dans ce stage va consister à suivre cette optique mais en visant la construction d’architectures sécurisé à partir d'un modèle UML d'un système multi-organisationnel. Ainsi, au lieu de ne considérer qu'un contrôle d'accès basé sur les rôles (RBAC, pour Role-based Access Control), nous allons tenir compte du contrôle d'accès plus large basé sur les organisations.
Il s'agit donc d'un travail de conceptualisation et d'implémentation en J2EE ou .NET, à l'instar de ce qui a été fait pour RBAC.
Outils : J2EE, .NET, Politiques de sécurité à base d'organisations (OrBAC)
|
| Durée : 4 à 6 mois | Niveau : Linux, IPSec, évaluation des performances |
IPSec est le standard de sécurité au niveau IP. Il est bien connu, approuvé et stable. Néanmoins, lors du chiffrement des données d'entête IP, IPSec rends impossible le contrôle active d'admission pour la QoS. Notre travail part du fait que pour gérer les ressources réseau et assurer la QoS, les “Multi-Field packet classifiers” classifient chaque paquet en prenant en considération plusieurs informations des entêtes IP/TCP (adresses et ports source et destination ainsi que l'identifiant du protocole de niveau 4), identifient le flux concerné par le paquet, et selon ces informations, fournissent le service approprié dans les réseaux IP.
Notons au passage que pour classifier un paquet, une priorité lui est assignée; celle-ci est enregistrée dans le champ ToS de l'entête Ipv4 (dit "trafic Class" dans IPv6). Néanmoins, pour des raisons de sécurité, les protocoles de sécurité (tels que IPSec ESP, SSH) chiffrent les entêtes IP/TCP, empêchant ainsi les équipements réseaux (e.g., routeurs, passerelles) de faire la classification et donc de fournir la QoS.
Pour pallier ces problèmes nous proposons d'ajouter, en claire les 5 champs (adresses et ports source et destination ainsi que l'identifiant du protocole de niveau 4) dans le protocole IPSec ESP. Ceci nous permettra donc de pouvoir faire de la QoS. Le travail qui sera mené peut être divisé en deux partie. Dans la première partie, il faut modifier la partie IPSec du noyeau Linux 2.6 afin d'ajouter les 5 champs en claire.
La deuxième parte consiste à mettre en place une
plateforme de test afin de comparer les performances d'ESP
et de son amélioration ( qui sera implémentée dans la
première partie de ce travail). Les mesures vont être
centrés sur le temps de traitement des paquets, le
débit, le délai, la gigue et le taux de perte.
|
| Durée : 4 à 6 mois | motscles securite et surete de fonctionnement, IDS, SNORT, arbres de defaillances, UML |
SNORT est le système de détection d'intrusion
réseau (IDS) le plus déployé au monde. Néanmoins, à
ce jour, aucun travail ne permet d'établir ses modes de
défaillance en vue de son test et son évaluation.
Récemment, la NASA a fait des publication (et même des
outils) qui permettent de dériver les modes de
défaillances à partir d'une modélisation UML. D'un
autre côté, des diagrammes UML pour SNORT sont
disponibles. L'idée est de se baser sur ces diagrammes
pour établir l'arbre de défaillance de SNORT, selon la
méthode de la NASA. Une fois cet arbre définie, on peut
éventuellement la quantifier (pour avoir à la fois une
évaluation qualitative et quantitative). Pour cela, il
faut mettre l'IDS sous test, en phase d'expérimentation,
afin qu'étiqueter les arcs de l'arbre selon les
statistiques de défaillances de l'IDS (sous test).
|
Encadrements pédagogique antérieurs |
| Année | Niveau | Sujet | ||||||
| 2006 - 2007 | 2ème année STI |
|
||||||
| 2005 - 2006 | 2ème année STI |
|
||||||
| 2004 - 2005 | 3ème année STI |
|
||||||
| 2ème année STI |
|
|||||||
| 1ère année STI |
|
|||||||
| 2003 - 2004 | Maîtrise Informatique
(Projets de fin d'étude) |
|
